Skip to contentSkip to conversation

Out of order unwind entry warning

DISCUSSION Helge Deller 6 participants 42 messages Oct 26, 2009 – Nov 7, 2009 PA-RISC architecture

lore
Share & tools
lore

Helge Deller

author maintainer
#0 lore raw

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

In my kernel I could track it down to 2 symbols:
- arch_mod_section_prepend() from kernel/module.c, and
- save_stack_trace_tsk().

Here is the extract of the readelf output on vmlinux:
...
<inb>: [0x1011fbd4-0x1011fc48]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
...

same for "save_stack_trace_tsk":

<dump_trace>: [0x10120834-0x10120950]
Entry_GR=7 Save_SP Save_RP Total_frame_size=80
<save_stack_trace_tsk>: [0x10120954-0x101209a4]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace_tsk>: [0x10120954-0x1015c7a8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace>: [0x101209a8-0x10120a04]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

as you can see, both functions (weak and non-weak) are in the unwind section, although the functions were only linked once each into the vmlinux binary.

That said, maybe someone of you with binutils/ld knowledge have some idea or hint how to fix this (aka drop the weak entry completely from the unwind section) ?
If not, I'll continue to dig into the binutils sources (although this takes time, as I'm just starting with this)...

Helge

#1 lore raw
Quoted 8 lines · Helge Deller

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

Looks like you did some good sleuthing... Although... I notice that ia64 doesn't seem to bother to do this sanity check on the unwind table.

tausq, should we just drop it in ours too? I can't see any evidence ia64 does anything differently in bfd that would circumvent this kind of issue.

regards, Kyle

#2 lore raw
Quoted 6 lines

Looks like you did some good sleuthing... Although... I notice that ia64 doesn't seem to bother to do this sanity check on the unwind table.

tausq, should we just drop it in ours too? I can't see any evidence ia64 does anything differently in bfd that would circumvent this kind of issue.

IIRC we do a binary search for the unwind entry. If the entries are not sorted, the binary search will give wrong results.

randolph

#3 lore raw
Quoted 10 lines · Randolph Chung
Quoted 6 lines

Looks like you did some good sleuthing... Although... I notice that ia64 doesn't seem to bother to do this sanity check on the unwind table.

tausq, should we just drop it in ours too? I can't see any evidence ia64 does anything differently in bfd that would circumvent this kind of issue.

IIRC we do a binary search for the unwind entry. If the entries are not sorted, the binary search will give wrong results.

Indeed, would be interesting to add this sanity check to ia64 and see what happens.

regards, Kyle

#4 lore raw
In reply to Helge Deller
Quoted 13 lines

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

In my kernel I could track it down to 2 symbols:
- arch_mod_section_prepend() from kernel/module.c, and
- save_stack_trace_tsk().

Quoted 11 lines

Here is the extract of the readelf output on vmlinux:
...
<inb>: [0x1011fbd4-0x1011fc48]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
...

It might be useful to know the actual location arch_mod_section_prepend and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#5 lore raw
Quoted 25 lines · John David Anglin
Quoted 13 lines

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

In my kernel I could track it down to 2 symbols:
- arch_mod_section_prepend() from kernel/module.c, and
- save_stack_trace_tsk().

Quoted 11 lines

Here is the extract of the readelf output on vmlinux:
...
<inb>: [0x1011fbd4-0x1011fc48]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
...

Quoted 5 lines

It might be useful to know the actual location arch_mod_section_prepend and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

arch_mod_section_prepend() is here:
* arch/parisc/kernel/module.c - non-weak function
* kernel/module.c - weak function

inb() is not defined in arch/parisc/kernel/module.c.
But during kernel build, all object files in arch/parisc/kernel/*.o are linked together into arch/parisc/kernel/built-in.o:

Running readelf: "hppa-linux-readelf -u arch/parisc/kernel/built-in.o" gives:
...
<inb>: [0x0-0xe8]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x0-0x50]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x0-0x80]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

So, yes, the non-weak arch_mod_section_prepend() function follows the inb() function in the object file (and in the final vmlinux file as well).

Quoted 4 lines
Quoted 4 lines

<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8

The first entry is the non-weak one.
The second entry is the remaining part of the weak (dropped) function. It seems only the start address was changed to the start address of the non-weak function, while the end address has been kept unchanged. [0x1011fc4c-0x10167cf4] would mean, that the weak function would be 295KB in size...?

Helge

author maintainer
#6 lore raw

Hi Dave,

Quoted 3 lines · John David Anglin
Quoted 2 lines

From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected.

What do you mean with "garbage collected" ? "dropped from the executable" ? AFAICS, the weak function was completely dropped from the vmlinux file.

Some more info:
The unwind function in the parisc linux kernel walks the (sorted!) unwind list. If one entry is wrong this can lead to incorrect unwinding.

In this case:

<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74] - non-weak function
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4] - weak function
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

I see a those options:
a) drop the second (weak) unwind info entry
b) for the weak function, use the same start- and end-addresses as the non-weak entry.

Option b) would probably need some adjustments to the existing parisc specific unwind function.

Helge

#10 lore raw
In reply to Helge Deller
Quoted 57 lines · John David Anglin
Quoted 25 lines
Quoted 13 lines

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

In my kernel I could track it down to 2 symbols:
- arch_mod_section_prepend() from kernel/module.c, and
- save_stack_trace_tsk().

Quoted 11 lines

Here is the extract of the readelf output on vmlinux:
...
<inb>: [0x1011fbd4-0x1011fc48]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
...

Quoted 5 lines

It might be useful to know the actual location arch_mod_section_prepend and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

arch_mod_section_prepend() is here:
* arch/parisc/kernel/module.c - non-weak function
* kernel/module.c - weak function

inb() is not defined in arch/parisc/kernel/module.c.
But during kernel build, all object files in arch/parisc/kernel/*.o are linked together into arch/parisc/kernel/built-in.o:

Running readelf: "hppa-linux-readelf -u arch/parisc/kernel/built-in.o" gives:
...
<inb>: [0x0-0xe8]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x0-0x50]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x0-0x80]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

So, yes, the non-weak arch_mod_section_prepend() function follows the inb() function in the object file (and in the final vmlinux file as well).

Quoted 4 lines
Quoted 4 lines

<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8

Quoted 5 lines

The first entry is the non-weak one.
The second entry is the remaining part of the weak (dropped) function. It seems only the start address was changed to the start address of the non-weak function, while the end address has been kept unchanged. [0x1011fc4c-0x10167cf4] would mean, that the weak function would be 295KB in size...?

If you run readelf on built-in.o, is the problem present there?

Does this happen with both 32 and 64 bit kernels?

Need to figure out why the start address of the weak function is the same as the non-weak function. My initial guess is that RELOC_FOR_GLOBAL_SYMBOL is messing up.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#11 lore raw
Quoted 57 lines · John David Anglin
Quoted 57 lines · John David Anglin
Quoted 25 lines
Quoted 13 lines

I started to look into the problem why we get the

Quoted 1 line

WARNING: Out of order unwind entry!

warning messages at kernel bootup in dmesg.

It's related to a binutils/linker bug, that ld does not correctly removes unlink information for unused weak symbols, which have been replaced by their non-weak ones.

In my kernel I could track it down to 2 symbols:
- arch_mod_section_prepend() from kernel/module.c, and
- save_stack_trace_tsk().

Quoted 11 lines

Here is the extract of the readelf output on vmlinux:
...
<inb>: [0x1011fbd4-0x1011fc48]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
...

Quoted 5 lines

It might be useful to know the actual location arch_mod_section_prepend and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

arch_mod_section_prepend() is here:
* arch/parisc/kernel/module.c - non-weak function
* kernel/module.c - weak function

inb() is not defined in arch/parisc/kernel/module.c.
But during kernel build, all object files in arch/parisc/kernel/*.o are linked together into arch/parisc/kernel/built-in.o:

Running readelf: "hppa-linux-readelf -u arch/parisc/kernel/built-in.o" gives:
...
<inb>: [0x0-0xe8]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<arch_mod_section_prepend>: [0x0-0x50]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x0-0x80]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

So, yes, the non-weak arch_mod_section_prepend() function follows the inb() function in the object file (and in the final vmlinux file as well).

Quoted 4 lines
Quoted 4 lines

<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4]
Entry_GR=1 Save_SP Total_frame_size=8

Quoted 7 lines
Quoted 5 lines

The first entry is the non-weak one.
The second entry is the remaining part of the weak (dropped) function. It seems only the start address was changed to the start address of the non-weak function, while the end address has been kept unchanged. [0x1011fc4c-0x10167cf4] would mean, that the weak function would be 295KB in size...?

If you run readelf on built-in.o, is the problem present there?

No. Since built-in.o is just an intermediate file, offset starts at 0x0. <arch_mod_section_prepend>: [0x0-0x50]
Entry_GR=1 Save_SP Total_frame_size=8
-> seems correct.

Quoted 1 line

Does this happen with both 32 and 64 bit kernels?

Yes.

Quoted 3 lines

Need to figure out why the start address of the weak function is the same as the non-weak function. My initial guess is that RELOC_FOR_GLOBAL_SYMBOL is messing up.

Helge

author maintainer
#12 lore raw
Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 4 lines
Quoted 4 lines

and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Attached is a testcase (t1.c and t2.c):
t1.c contains weak function f().
t2.c contains non-weak function f().

hppa-linux-gcc -c t1.c t2.c
hppa-linux-ld -r -o all.o t1.o t2.o

hppa-linux-readelf -s t1.o gives:
Symbol table '.symtab' contains 10 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     6: 00000000    28 FUNC    GLOBAL DEFAULT    1 a
     7: 0000001c    32 FUNC    WEAK   DEFAULT    1 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main

hppa-linux-readelf -s t2.o gives:
Symbol table '.symtab' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name

     6: 00000000    32 FUNC    GLOBAL DEFAULT    1 f

hppa-linux-readelf -s all.o gives:
Symbol table '.symtab' contains 11 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     7: 00000000    32 FUNC    GLOBAL DEFAULT    3 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main
    10: 00000000    28 FUNC    GLOBAL DEFAULT    1 a

hppa-linux-readelf -u all.o gives:
Unwind section '.PARISC.unwind' at offset 0xfc contains 5 entries:
<a>: [0x0-0x30]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x0-0x70]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x3c-0xa8]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x58-0x148]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<f>: [0x0-0x38]
Entry_GR=1 Save_SP Total_frame_size=8

Function f() is listed twice and with different lengths. Sadly in this example f() starts at offset 0. I think if you tweak the example, try to see what you get when the start of f() is not zero.

Helge
/who has to run now...

int a(void)

{
	return 1;
}

int __attribute__((weak)) f(int x)

{
	return 0;
}

int z(void)

{
	return 2;
}

int main(void)

{
	return a() + f(0) + z();
}
int f(int x)
{
	return 500;
}
#7 lore raw
In reply to Helge Deller
Quoted 8 lines

Hi Dave,

Quoted 3 lines · John David Anglin
Quoted 2 lines

From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected.

What do you mean with "garbage collected" ? "dropped from the executable" ? AFAICS, the weak function was completely dropped from the vmlinux file.

Yes, I mean "dropped from the executable". Dropping weak functions is trickier than just leaving them in place. It is easier to just adjust the linkage. The default behavior of HP ld is to leave unused functions. Don't know about GNU ld. If GNU ld drops unused weak functions, then the PARISC.unwind entries for them need to be removed.

Quoted 13 lines

Some more info:
The unwind function in the parisc linux kernel walks the (sorted!) unwind list. If one entry is wrong this can lead to incorrect unwinding.

In this case:

<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74] - non-weak function
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc4c-0x10167cf4] - weak function
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc78-0x1011fcb8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

Quoted 6 lines

I see a those options:
a) drop the second (weak) unwind info entry
b) for the weak function, use the same start- and end-addresses as the non-weak entry.

Option b) would probably need some adjustments to the existing parisc specific unwind function.

I'm not keen about b). From looking at one of my builds, it does indeed look like the weak version of arch_mod_section_prepend has been dropped (can only find one copy with objdump).

Do you know if linux uses the --gc-sections ld option? This together with the GCC -function-sections option might contribute to this problem.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#13 lore raw
In reply to Helge Deller
Quoted 49 lines · Helge Deller
Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 4 lines
Quoted 4 lines

and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Attached is a testcase (t1.c and t2.c):
t1.c contains weak function f().
t2.c contains non-weak function f().

hppa-linux-gcc -c t1.c t2.c
hppa-linux-ld -r -o all.o t1.o t2.o

hppa-linux-readelf -s t1.o gives:
Symbol table '.symtab' contains 10 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     6: 00000000    28 FUNC    GLOBAL DEFAULT    1 a
     7: 0000001c    32 FUNC    WEAK   DEFAULT    1 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main

hppa-linux-readelf -s t2.o gives:
Symbol table '.symtab' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name

     6: 00000000    32 FUNC    GLOBAL DEFAULT    1 f

hppa-linux-readelf -s all.o gives:
Symbol table '.symtab' contains 11 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     7: 00000000    32 FUNC    GLOBAL DEFAULT    3 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main
    10: 00000000    28 FUNC    GLOBAL DEFAULT    1 a

hppa-linux-readelf -u all.o gives:
Unwind section '.PARISC.unwind' at offset 0xfc contains 5 entries:
<a>: [0x0-0x30]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x0-0x70]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x3c-0xa8]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x58-0x148]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<f>: [0x0-0x38]
Entry_GR=1 Save_SP Total_frame_size=8

Quoted 3 lines

Function f() is listed twice and with different lengths. Sadly in this example f() starts at offset 0. I think if you tweak the example, try to see what you get when the start of f() is not zero.

Looking at all.o with objdump, the code for <f> is still present. I would say the regions should be:

<a>: [0x0-0x18]
<f>: [0x1c-0x38]
<z>: [0x3c-0x54]
<main>: [0x58-0xa4]
<f>: [0x0-0x1c]

There are two .text sections, so the offsets for the second <f> are relative to the start of this section.

My compilation probably differs a bit from yours but I see the same readelf -u output. Suspect readelf is broken. The end values seem off by a factor 2.

Need to see why start for first <f> is wrong and what happens in final link.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#9 lore raw
In reply to Helge Deller
Quoted 7 lines · Helge Deller

I see a those options:
a) drop the second (weak) unwind info entry
b) for the weak function, use the same start- and end-addresses as the non-weak entry.

Option b) would probably need some adjustments to the existing parisc specific unwind function.

FWIW I think option (a) is the best option.

Yes, the linker doesn't even consider the weak function when building the final executable, I don't know why an unwind entry is kept for it.

Be aware that --gc-sections can cause similar problems in unwind information on other targets, so it might also be an issue for PARISC.

Thanks for the good work so far!

Cheers,
Carlos.

#14 lore raw
In reply to John David Anglin
Quoted 64 lines · John David Anglin
Quoted 49 lines · Helge Deller
Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 4 lines
Quoted 4 lines

and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Attached is a testcase (t1.c and t2.c):
t1.c contains weak function f().
t2.c contains non-weak function f().

hppa-linux-gcc -c t1.c t2.c
hppa-linux-ld -r -o all.o t1.o t2.o

hppa-linux-readelf -s t1.o gives:
Symbol table '.symtab' contains 10 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     6: 00000000    28 FUNC    GLOBAL DEFAULT    1 a
     7: 0000001c    32 FUNC    WEAK   DEFAULT    1 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main

hppa-linux-readelf -s t2.o gives:
Symbol table '.symtab' contains 7 entries:
Num: Value Size Type Bind Vis Ndx Name

     6: 00000000    32 FUNC    GLOBAL DEFAULT    1 f

hppa-linux-readelf -s all.o gives:
Symbol table '.symtab' contains 11 entries:

   Num:    Value  Size Type    Bind   Vis      Ndx Name
     7: 00000000    32 FUNC    GLOBAL DEFAULT    3 f
     8: 0000003c    28 FUNC    GLOBAL DEFAULT    1 z
     9: 00000058    80 FUNC    GLOBAL DEFAULT    1 main
    10: 00000000    28 FUNC    GLOBAL DEFAULT    1 a

hppa-linux-readelf -u all.o gives:
Unwind section '.PARISC.unwind' at offset 0xfc contains 5 entries:
<a>: [0x0-0x30]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x0-0x70]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x3c-0xa8]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x58-0x148]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<f>: [0x0-0x38]
Entry_GR=1 Save_SP Total_frame_size=8

Quoted 3 lines

Function f() is listed twice and with different lengths. Sadly in this example f() starts at offset 0. I think if you tweak the example, try to see what you get when the start of f() is not zero.

Looking at all.o with objdump, the code for <f> is still present. I would say the regions should be:

<a>: [0x0-0x18]
<f>: [0x1c-0x38]
<z>: [0x3c-0x54]
<main>: [0x58-0xa4]
<f>: [0x0-0x1c]

Quoted 6 lines

There are two .text sections, so the offsets for the second <f> are relative to the start of this section.

My compilation probably differs a bit from yours but I see the same readelf -u output. Suspect readelf is broken. The end values seem off by a factor 2.

readelf -u is definitely broken when used on an object without program headers.

However, I think we are creating trouble for ourself by using the function's symbol name for the start offset in the unwind table:

Relocation section '.rela.PARISC.unwind' at offset 0x3d8 contains 10 entries:
Offset Info Type Sym.Value Sym. Name + Addend

00000000  00000a31 R_PARISC_SEGREL32 00000000   a + 0
00000004  00000131 R_PARISC_SEGREL32 00000000   .text + 18
00000010  00000731 R_PARISC_SEGREL32 00000000   f + 0
00000014  00000131 R_PARISC_SEGREL32 00000000   .text + 38
00000020  00000831 R_PARISC_SEGREL32 0000003c   z + 0
00000024  00000131 R_PARISC_SEGREL32 00000000   .text + 54
00000030  00000931 R_PARISC_SEGREL32 00000058   main + 0
00000034  00000131 R_PARISC_SEGREL32 00000000   .text + a4
00000040  00000731 R_PARISC_SEGREL32 00000000   f + 0
00000044  00000231 R_PARISC_SEGREL32 00000000   .text + 1c

I think the assembler needs to be changed to use local symbols for the start that will be reduced to section offsets. This should prevent the problem with wrong ranges. However, there may be issues with finding the symbol associated with a range in readelf, etc.

Thoughts?

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#15 lore raw
In reply to Helge Deller
Quoted 7 lines · Helge Deller
Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 4 lines
Quoted 4 lines

and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Quoted 6 lines

Attached is a testcase (t1.c and t2.c):
t1.c contains weak function f().
t2.c contains non-weak function f().

hppa-linux-gcc -c t1.c t2.c
hppa-linux-ld -r -o all.o t1.o t2.o

Attached is a patch for gas that seems to produce reasonable unwind info for the testcase when all.o is linked into a final executable. I think it will fix the linux unwind problem.

Still need to look at readelf -u on .o's.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.145

tc-hppa.c +30 -2
diff -u -3 -p -r1.145 tc-hppa.c
@@ -5961,13 +5961,41 @@ pa_build_unwind_subspace (struct call_in
   subsegT save_subseg;
   unsigned int unwind;
   int reloc;
-  char *p;
+  char *name, *p;
+  symbolS *symbolP;
 
   if ((bfd_get_section_flags (stdoutput, now_seg)
        & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
       != (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
     return;
 
+  /* Replace the start symbol with a local symbol that will be reduced
+     to a section offset.  This avoids problems with weak functions with
+     multiple definitions, etc.  */
+  name = xmalloc (strlen ("L$\001start_")
+		  + strlen (S_GET_NAME (call_info->start_symbol))
+		  + 1);
+  strcpy (name, "L$\001start_");
+  strcat (name, S_GET_NAME (call_info->start_symbol));
+
+  /* If we have a .procend preceded by a .exit, then the symbol will have
+     already been defined.  In that case, we don't want another unwind
+     entry.  */
+  symbolP = symbol_find (name);
+  if (symbolP)
+    {
+      xfree (name);
+      return;
+    }
+  else
+    {
+      symbolP = symbol_new (name, now_seg,
+			    S_GET_VALUE (call_info->start_symbol), frag_now);
+      gas_assert (symbolP);
+      S_CLEAR_EXTERNAL (symbolP);
+      symbol_table_insert (symbolP);
+    }
+
   reloc = R_PARISC_SEGREL32;
   save_seg = now_seg;
   save_subseg = now_subseg;

@@ -5993,7 +6021,7 @@ pa_build_unwind_subspace (struct call_in
   /* Relocation info. for start offset of the function.  */
   md_number_to_chars (p, 0, 4);
   fix_new_hppa (frag_now, p - frag_now->fr_literal, 4,
-		call_info->start_symbol, (offsetT) 0,
+		symbolP, (offsetT) 0,
 		(expressionS *) NULL, 0, reloc,
 		e_fsel, 32, 0, 0);
author maintainer
#16 lore raw
Quoted 13 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 5 lines · Helge Deller
Quoted 4 lines · John David Anglin
Quoted 4 lines
Quoted 4 lines

and whether it follows inb in its .o. From my understanding of things, it shouldn't be necessary to remove the unwind info for unused weak symbols if they aren't garbage collected. A simple testcase would be helpful.

Attached is a testcase (t1.c and t2.c):
t1.c contains weak function f().
t2.c contains non-weak function f().

Quoted 6 lines
Quoted 2 lines

hppa-linux-gcc -c t1.c t2.c
hppa-linux-ld -r -o all.o t1.o t2.o

Attached is a patch for gas that seems to produce reasonable unwind info for the testcase when all.o is linked into a final executable. I think it will fix the linux unwind problem.

Hi Dave,

Yes, this patch fixes the problem for vmlinux :-)
Just tested it with a 32bit kernel build.

Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Thanks!

Helge

author maintainer
#8 lore raw
In reply to John David Anglin
Quoted 2 lines · John David Anglin

Do you know if linux uses the --gc-sections ld option? This together with the GCC -function-sections option might contribute to this problem.

The --gc-sections ld option is not used.
gcc's -function-sections is used.

Helge

#17 lore raw
In reply to Helge Deller
Quoted 5 lines
Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Actually, the entries are still there. For weak functions that are not used, they appear as "<foo+x>:" where foo is the closest preceding symbol before the unused weak function. In practice, the code shouldn't be entered, so the lack of an associated function symbol shouldn't matter.

I have a fix for the readelf -u bug. See below.

Dave

Signature · 24 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.467
diff -u -3 -p -r1.467 readelf.c
--- readelf.c	23 Oct 2009 00:15:07 -0000	1.467
+++ readelf.c	29 Oct 2009 20:59:26 -0000
@@ -5589,11 +5589,11 @@ slurp_hppa_unwind_table (FILE * file,
 	    {
 	    case 0:
 	      aux->table[i].start.section = sym->st_shndx;
-	      aux->table[i].start.offset += sym->st_value + rp->r_addend;
+	      aux->table[i].start.offset  = sym->st_value + rp->r_addend;
 	      break;
 	    case 1:
 	      aux->table[i].end.section   = sym->st_shndx;
-	      aux->table[i].end.offset   += sym->st_value + rp->r_addend;
+	      aux->table[i].end.offset    = sym->st_value + rp->r_addend;
 	      break;
 	    default:
 	      break;
author maintainer
#18 lore raw
Quoted 6 lines · John David Anglin
Quoted 5 lines
Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Quoted 7 lines

Actually, the entries are still there. For weak functions that are not used, they appear as "<foo+x>:" where foo is the closest preceding symbol before the unused weak function. In practice, the code shouldn't be entered, so the lack of an associated function symbol shouldn't matter.

I have a fix for the readelf -u bug. See below.

Sorry, but I don't fully understand...

With your patch to gas, the unwind info for the weak functions are completely gone in the final executable (which is good).

But "readelf -u" doesn't show the "Entry_GR=..." lines for _any_ function any longer (in the final executable). I really mean _all_ functions, weak, non-weak, standard, ...
The patch you attached only changes the start and end addresses of the symbols...?

Helge

#19 lore raw
Quoted 14 lines · John David Anglin
Quoted 12 lines
Quoted 5 lines
Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Actually, the entries are still there. For weak functions that are not used, they appear as "<foo+x>:" where foo is the closest preceding symbol before the unused weak function. In practice, the code shouldn't be entered, so the lack of an associated function symbol shouldn't matter.

Quoted 5 lines
Quoted 1 line

I have a fix for the readelf -u bug. See below.

Sorry, but I don't fully understand...

With your patch to gas, the unwind info for the weak functions are completely gone in the final executable (which is good).

I don't think I changed this. In the testcase that you sent, I see

<a>: [0x104a0-0x104b8]
Entry_GR=1 Save_SP Total_frame_size=8
<a+1c>: [0x104bc-0x104d8]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x104dc-0x104f4]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x104f8-0x10544]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x10548-0x10564]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

The weak version of f is the <a+1c> entry.

Quoted 2 lines

But "readelf -u" doesn't show the "Entry_GR=..." lines for _any_ function any longer (in the final executable). I really mean _all_ functions, weak, non-weak, standard, ...

That's not what I'm seeing. The old and new versions seem similar (i.e., with respect to missing "Entry_GR=..."). Didn't touch the code that extracts and prints this stuff.

The lack of "Entry_GR=..." stuff for an entry probably indicates that there isn't a .CALLINFO directive for the function in question. This could happen if the function is handcoded assembler. However, it is legitimate for a function not to have any of the unwind stuff set (e.g., function doesn't save any registers or allocate a frame). I think GCC gets this right but it never has been looked at with a magnifying glass.

Quoted 1 line

The patch you attached only changes the start and end addresses of the symbols...?

Yes, and only for .o's. In final executables, there are no relocations in the .PARISC.unwind section. So, the values printed should be unaffected.

In the .o case, the code was in effect doing the SEGREL relocation twice leading to offsets twice as big as they should have been. It still runs through the relocations if present, but uses the value from doing the relocation if one is present. Compare what you see now with objdump -d and readelf -u on a .o.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#20 lore raw
Quoted 52 lines · John David Anglin
Quoted 14 lines · John David Anglin
Quoted 12 lines
Quoted 5 lines
Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Actually, the entries are still there. For weak functions that are not used, they appear as "<foo+x>:" where foo is the closest preceding symbol before the unused weak function. In practice, the code shouldn't be entered, so the lack of an associated function symbol shouldn't matter.

Quoted 5 lines
Quoted 1 line

I have a fix for the readelf -u bug. See below.

Sorry, but I don't fully understand...

With your patch to gas, the unwind info for the weak functions are completely gone in the final executable (which is good).

I don't think I changed this. In the testcase that you sent, I see

<a>: [0x104a0-0x104b8]
Entry_GR=1 Save_SP Total_frame_size=8
<a+1c>: [0x104bc-0x104d8]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x104dc-0x104f4]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x104f8-0x10544]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x10548-0x10564]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

The weak version of f is the<a+1c> entry.

Quoted 2 lines

But "readelf -u" doesn't show the "Entry_GR=..." lines for _any_ function any longer (in the final executable). I really mean _all_ functions, weak, non-weak, standard, ...

That's not what I'm seeing. The old and new versions seem similar (i.e., with respect to missing "Entry_GR=..."). Didn't touch the code that extracts and prints this stuff.

The lack of "Entry_GR=..." stuff for an entry probably indicates that there isn't a .CALLINFO directive for the function in question. This could happen if the function is handcoded assembler. However, it is legitimate for a function not to have any of the unwind stuff set (e.g., function doesn't save any registers or allocate a frame). I think GCC gets this right but it never has been looked at with a magnifying glass.

Quoted 1 line

The patch you attached only changes the start and end addresses of the symbols...?

Quoted 8 lines

Yes, and only for .o's. In final executables, there are no relocations in the .PARISC.unwind section. So, the values printed should be unaffected.

In the .o case, the code was in effect doing the SEGREL relocation twice leading to offsets twice as big as they should have been. It still runs through the relocations if present, but uses the value from doing the relocation if one is present. Compare what you see now with objdump -d and readelf -u on a .o.

Hi Dave,

you are probably correct. Nevertheless, your patches seem to have side-effects. With your patches, the testcase from me now looks correct (as you explained above).

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

This is what I get with your patches:
/opt/cross-hppa-4.4.neu/bin/hppa-linux-readelf -u vmlinux
...
--------------------------------------------------------------
<arch_mod_section_prepend>: [0x1011fc00-0x1011fc28]

<module_arch_cleanup>: [0x1011fc2c-0x1011fc6c]

<apply_relocate>: [0x1011fc70-0x1011fca4]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<module_finalize>: [0x1011fca8-0x1011fe8c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=24
<get_stub>: [0x1011fe90-0x1011ffb4]

<apply_relocate_add>: [0x1011ffb8-0x101205b8]

<module_frob_arch_sections>: [0x101205bc-0x10120758]

<module_free>: [0x1012075c-0x101207a4]

<module_alloc>: [0x101207a8-0x101207e4]

<dump_trace>: [0x101207e8-0x10120904]

<save_stack_trace_tsk>: [0x10120908-0x10120958]

<save_stack_trace>: [0x1012095c-0x101209b8]

<sgl_frnd>: [0x101209bc-0x10120b8c]
Entry_GR=1 Save_SP Total_frame_size=8
<dbl_frnd>: [0x10120b90-0x10120e74]
Entry_GR=1 Save_SP Total_frame_size=8
--------------------------------------------------------------

As you can see, a few Entry_GR lines are missing.
Even for C-functions for which Entry_GR was there with the old toolchain. I sadly can not see any reason or logic in why specific functions don't have their Entry_GR lines any longer.

Here for reference what I see with the old (unpatched) toolchain:
(as you can see arch_mod_section_prepend() is there twice again -> because of the old unpatched toolchain)

--------------------------------------------------------------
/opt/cross-hppa-4.4/bin/hppa-linux-readelf -u vmlinux
...
<arch_mod_section_prepend>: [0x1011fc00-0x1011fc28]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc00-0x10167dec]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc2c-0x1011fc6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<apply_relocate>: [0x1011fc70-0x1011fca4]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<module_finalize>: [0x1011fca8-0x1011fe8c]
Entry_GR=11 Save_SP Save_RP Total_frame_size=16
<get_stub>: [0x1011fe90-0x1011ffb4]
Entry_GR=1 Save_SP Total_frame_size=8
<apply_relocate_add>: [0x1011ffb8-0x101205b8]
Entry_GR=16 Save_SP Save_RP Total_frame_size=24
<module_frob_arch_sections>: [0x101205bc-0x10120758]
Entry_GR=10 Save_SP Save_RP Total_frame_size=16
<module_free>: [0x1012075c-0x101207a4]
Entry_GR=3 Save_SP Save_RP Total_frame_size=8
<module_alloc>: [0x101207a8-0x101207e4]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<dump_trace>: [0x101207e8-0x10120904]
Entry_GR=7 Save_SP Save_RP Total_frame_size=80
<save_stack_trace_tsk>: [0x10120908-0x10120958]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace_tsk>: [0x10120908-0x1015c7ac]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace>: [0x1012095c-0x101209b8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<sgl_frnd>: [0x101209bc-0x10120b8c]
Entry_GR=1 Save_SP Total_frame_size=8
<dbl_frnd>: [0x10120b90-0x10120e74]
Entry_GR=1 Save_SP Total_frame_size=8
--------------------------------------------------------------

Helge

#21 lore raw
Quoted 143 lines · John David Anglin
Quoted 52 lines
Quoted 14 lines · John David Anglin
Quoted 12 lines
Quoted 5 lines
Quoted 1 line

Still need to look at readelf -u on .o's.

Yes, I see this too. readelf -u doesn't print any longer the second line of:
<arch_mod_section_prepend>: [0x1011fc4c-0x1011fc74]
Entry_GR=1 Save_SP Total_frame_size=8

Actually, the entries are still there. For weak functions that are not used, they appear as "<foo+x>:" where foo is the closest preceding symbol before the unused weak function. In practice, the code shouldn't be entered, so the lack of an associated function symbol shouldn't matter.

Quoted 5 lines
Quoted 1 line

I have a fix for the readelf -u bug. See below.

Sorry, but I don't fully understand...

With your patch to gas, the unwind info for the weak functions are completely gone in the final executable (which is good).

I don't think I changed this. In the testcase that you sent, I see

<a>: [0x104a0-0x104b8]
Entry_GR=1 Save_SP Total_frame_size=8
<a+1c>: [0x104bc-0x104d8]
Entry_GR=1 Save_SP Total_frame_size=8
<z>: [0x104dc-0x104f4]
Entry_GR=1 Save_SP Total_frame_size=8
<main>: [0x104f8-0x10544]
Entry_GR=1 Save_SP Total_frame_size=8
<f>: [0x10548-0x10564]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

The weak version of f is the<a+1c> entry.

Quoted 2 lines

But "readelf -u" doesn't show the "Entry_GR=..." lines for _any_ function any longer (in the final executable). I really mean _all_ functions, weak, non-weak, standard, ...

That's not what I'm seeing. The old and new versions seem similar (i.e., with respect to missing "Entry_GR=..."). Didn't touch the code that extracts and prints this stuff.

The lack of "Entry_GR=..." stuff for an entry probably indicates that there isn't a .CALLINFO directive for the function in question. This could happen if the function is handcoded assembler. However, it is legitimate for a function not to have any of the unwind stuff set (e.g., function doesn't save any registers or allocate a frame). I think GCC gets this right but it never has been looked at with a magnifying glass.

Quoted 1 line

The patch you attached only changes the start and end addresses of the symbols...?

Quoted 8 lines

Yes, and only for .o's. In final executables, there are no relocations in the .PARISC.unwind section. So, the values printed should be unaffected.

In the .o case, the code was in effect doing the SEGREL relocation twice leading to offsets twice as big as they should have been. It still runs through the relocations if present, but uses the value from doing the relocation if one is present. Compare what you see now with objdump -d and readelf -u on a .o.

Hi Dave,

you are probably correct. Nevertheless, your patches seem to have side-effects. With your patches, the testcase from me now looks correct (as you explained above).

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

This is what I get with your patches:
/opt/cross-hppa-4.4.neu/bin/hppa-linux-readelf -u vmlinux
...
--------------------------------------------------------------
<arch_mod_section_prepend>: [0x1011fc00-0x1011fc28]

<module_arch_cleanup>: [0x1011fc2c-0x1011fc6c]

<apply_relocate>: [0x1011fc70-0x1011fca4]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<module_finalize>: [0x1011fca8-0x1011fe8c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=24
<get_stub>: [0x1011fe90-0x1011ffb4]

<apply_relocate_add>: [0x1011ffb8-0x101205b8]

<module_frob_arch_sections>: [0x101205bc-0x10120758]

<module_free>: [0x1012075c-0x101207a4]

<module_alloc>: [0x101207a8-0x101207e4]

<dump_trace>: [0x101207e8-0x10120904]

<save_stack_trace_tsk>: [0x10120908-0x10120958]

<save_stack_trace>: [0x1012095c-0x101209b8]

<sgl_frnd>: [0x101209bc-0x10120b8c]
Entry_GR=1 Save_SP Total_frame_size=8
<dbl_frnd>: [0x10120b90-0x10120e74]
Entry_GR=1 Save_SP Total_frame_size=8
--------------------------------------------------------------

As you can see, a few Entry_GR lines are missing.
Even for C-functions for which Entry_GR was there with the old toolchain. I sadly can not see any reason or logic in why specific functions don't have their Entry_GR lines any longer.

Here for reference what I see with the old (unpatched) toolchain:
(as you can see arch_mod_section_prepend() is there twice again -> because of the old unpatched toolchain)

--------------------------------------------------------------
/opt/cross-hppa-4.4/bin/hppa-linux-readelf -u vmlinux
...
<arch_mod_section_prepend>: [0x1011fc00-0x1011fc28]
Entry_GR=1 Save_SP Total_frame_size=8
<arch_mod_section_prepend>: [0x1011fc00-0x10167dec]
Entry_GR=1 Save_SP Total_frame_size=8
<module_arch_cleanup>: [0x1011fc2c-0x1011fc6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<apply_relocate>: [0x1011fc70-0x1011fca4]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<module_finalize>: [0x1011fca8-0x1011fe8c]
Entry_GR=11 Save_SP Save_RP Total_frame_size=16
<get_stub>: [0x1011fe90-0x1011ffb4]
Entry_GR=1 Save_SP Total_frame_size=8
<apply_relocate_add>: [0x1011ffb8-0x101205b8]
Entry_GR=16 Save_SP Save_RP Total_frame_size=24
<module_frob_arch_sections>: [0x101205bc-0x10120758]
Entry_GR=10 Save_SP Save_RP Total_frame_size=16
<module_free>: [0x1012075c-0x101207a4]
Entry_GR=3 Save_SP Save_RP Total_frame_size=8
<module_alloc>: [0x101207a8-0x101207e4]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<dump_trace>: [0x101207e8-0x10120904]
Entry_GR=7 Save_SP Save_RP Total_frame_size=80
<save_stack_trace_tsk>: [0x10120908-0x10120958]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace_tsk>: [0x10120908-0x1015c7ac]

Quoted 8 lines

Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<save_stack_trace>: [0x1012095c-0x101209b8]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8
<sgl_frnd>: [0x101209bc-0x10120b8c]
Entry_GR=1 Save_SP Total_frame_size=8
<dbl_frnd>: [0x10120b90-0x10120e74]
Entry_GR=1 Save_SP Total_frame_size=8
--------------------------------------------------------------

It's not exactly clear what's going on. I would say that the old and new versions of readelf should produce identical results on the same kernel. The readelf change was only supposed to affect the output from .o's.

Looking at the code for arch_mod_section_prepend in one of my kernels, there are no saved registers and there is no frame allocated. Thus, the "Entry_GR=1 Save_SP Total_frame_size=8" printed by the old version of readelf might be wrong. However, you can't tell unless you compare the actual code with the readelf -u output.

There seems to a problem with readelf -u on 32-bit kernels. The address ranges are wrong. The segment offset doesn't seem to be being handled correctly.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#22 lore raw
Quoted 3 lines · John David Anglin

There seems to a problem with readelf -u on 32-bit kernels. The address ranges are wrong. The segment offset doesn't seem to be being handled correctly.

readelf -u uses the base address of the segment containing the .PARISC.unwind section. On 64-bit kernels, the .PARISC.unwind section is in the same segment as the .text section, so the addresses print are correct. However, on recent 32-bit kernels, this is not the case:

Section to Segment mapping:
Segment Sections...

   00     .text .rodata .init.rodata __bug_table .pci_fixup .builtin_fw __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param 
   01     __ex_table .PARISC.unwind .data.read_mostly .data .got .data.vmpages .bss 
   02     .data.init_task .init.text .init.data .init.setup .initcall.init .con_initcall.init .exit.text

03

.PARISC.unwind is readonly, so it shouldn't be in a W segment.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#23 lore raw
Quoted 12 lines · John David Anglin
Quoted 3 lines · John David Anglin

There seems to a problem with readelf -u on 32-bit kernels. The address ranges are wrong. The segment offset doesn't seem to be being handled correctly.

readelf -u uses the base address of the segment containing the .PARISC.unwind section. On 64-bit kernels, the .PARISC.unwind section is in the same segment as the .text section, so the addresses print are correct. However, on recent 32-bit kernels, this is not the case:

Quoted 8 lines

Section to Segment mapping:
Segment Sections...

    00     .text .rodata .init.rodata __bug_table .pci_fixup .builtin_fw __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param
    01     __ex_table .PARISC.unwind .data.read_mostly .data .got .data.vmpages .bss
    02     .data.init_task .init.text .init.data .init.setup .initcall.init .con_initcall.init .exit.text
    03

.PARISC.unwind is readonly, so it shouldn't be in a W segment.

apply the patch in http://patchwork.kernel.org/patch/55797/ before testing. .PARISC.unwind is then still in a RW segment, but at least you will get more reliable output.

Helge

#24 lore raw
In reply to Helge Deller
Quoted 4 lines · Helge Deller

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#25 lore raw
Quoted 10 lines · John David Anglin
Quoted 4 lines · Helge Deller

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

It seems the unwind data is being sorted by ld -r.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
#26 lore raw
Quoted 9 lines · John David Anglin
Quoted 7 lines · John David Anglin
Quoted 4 lines · Helge Deller

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

Quoted 5 lines
Quoted 3 lines

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

It seems the unwind data is being sorted by ld -r.

Does the attached patch fix the problem?

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.168

elf32-hppa.c +3 -0
diff -u -3 -p -r1.168 elf32-hppa.c
@@ -3238,6 +3238,9 @@ elf32_hppa_final_link (bfd *abfd, struct
 
   /* If we're producing a final executable, sort the contents of the
      unwind section.  */
+  if (info->relocatable)
+    return TRUE;
+
   return elf_hppa_sort_unwind (abfd);
 }

Index: elf64-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-hppa.c,v
retrieving revision 1.92

elf64-hppa.c +1 -1
diff -u -3 -p -r1.92 elf64-hppa.c
@@ -3033,7 +3033,7 @@ elf_hppa_final_link (bfd *abfd, struct b
 
   /* If we're producing a final executable, sort the contents of the
      unwind section. */
-  if (retval)
+  if (retval && !info->relocatable)
     retval = elf_hppa_sort_unwind (abfd);
 
   return retval;
author maintainer
#27 lore raw
Quoted 11 lines · John David Anglin
Quoted 9 lines · John David Anglin
Quoted 7 lines · John David Anglin
Quoted 4 lines · Helge Deller

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

It seems the unwind data is being sorted by ld -r.

Does the attached patch fix the problem?

Yes, it does :-)

All of your patches applied seem to work 100% OK.

Helge

PS: I only tested 32bit, but I assume 64bit will then work as well.

#28 lore raw
Quoted 16 lines · John David Anglin
Quoted 15 lines · John David Anglin
Quoted 14 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 5 lines

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

It seems the unwind data is being sorted by ld -r.

Does the attached patch fix the problem?

Yes, it does :-)

Thanks for testing! I have built a 32-bit kernel with the revised assembler and linker, and the readelf -u output looked good to me. I will install the remaining two changes tonight (the assembler change was installed a couple of days ago).

I haven't had a chance to boot the new kernel (waiting for a GCC build to complete). There is a USB issue that appeared on my c3750 with 2.6.30.9 (2.6.30.8 is ok) and 2.6.31.5. Here is the dmesg output from 2.6.31.5:

Linux version 2.6.31.5 (root@hiauly6) (gcc version 4.3.4 (Debian 4.3.4-5) ) #6 Sun Nov 1 14:20:36 EST 2009
unwind_init: start = 0x10524000, end = 0x10559a60, entries = 13734
FP[0] enabled: Rev 1 Model 19
The 32-bit Kernel has started...
...
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
...
usbmon: debugfs is not available
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:0e.2: OHCI Host Controller
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf4007000
...
usb usb1: configuration #1 chosen from 1 choice
sdb5
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
...
usb 1-1: new low speed USB device using ohci_hcd and address 2
EXT3-fs: mounted filesystem with writeback data mode.
VFS: Mounted root (ext3 filesystem) readonly on device 8:19.
Freeing unused kernel memory: 124k freed
usb 1-1: configuration #1 chosen from 1 choice
usb 1-2: new low speed USB device using ohci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
sysfs: cannot create duplicate filename '/module/usbhid/sections/.text'

------------[ cut here ]------------
Badness at fs/sysfs/dir.c:487

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not tainted

r00-03  0004000f 10576200 101cb5dc 4edc9000
r04-07  ffffffef 4fbb4288 4edc8a88 00074844
r08-11  4f8db000 00000000 00063000 00000064
r12-15  00000124 00067bbb 104c36a0 00000058
r16-19  00068fc8 00000062 4fbb4148 10576244
r20-23  00002b68 4f16bca0 0027f808 ffffffff
r24-27  ffffffff 00002b68 10576240 1055c2d0
r28-31  0000004e 00000000 4fbb4340 102a0244

sr00-03 00000000 00000000 00000000 00000010
sr04-07 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101cb5dc 101cb5e0
IIR: 03ffe01f ISR: 00000000 IOR: 00000000
CPU: 0 CR30: 4fbb4000 CR31: ffffffff
ORIG_R28: 00000001
IAOQ[0]: sysfs_add_one+0x8c/0xb4
IAOQ[1]: sysfs_add_one+0x90/0xb4
RP(r2): sysfs_add_one+0x8c/0xb4

Backtrace:
 [<101cadb0>] sysfs_add_file_mode+0x58/0xb4
 [<101cd4b4>] internal_create_group+0x118/0x1dc
 [<10158434>] load_module+0xf14/0x1214

input: Logitech N48 as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-1/1-1:1.0/input/input0 generic-usb 0003:046D:C001.0001: input: USB HID v1.00 Mouse [Logitech N48] on usb-0000:00:0e.2-1/input0
input: SILITEK USB Keyboard and Mouse as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-2/1-2:1.0/input/input1 generic-usb 0003:047B:0002.0002: input: USB HID v1.00 Keyboard [SILITEK USB Keyboard and Mouse] on usb-0000:00:0e.2-2/input0
input: SILITEK USB Keyboard and Mouse as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-2/1-2:1.1/input/input2 generic-usb 0003:047B:0002.0003: input: USB HID v1.00 Mouse [SILITEK USB Keyboard and Mouse] on usb-0000:00:0e.2-2/input1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
...

As you can see, there is a USB mouse and keyboard. Want to see backtrace with new assembler and linker. However, at the least the first part is consistent with the sysfs warning.

I "upgraded" this system to testing last weekend. The keyboard is broken under X. In gdm/kdm, one has to press a key twice. The Xorg.0.log seems ok:

(**) Option "CoreKeyboard"
(**) Generic Keyboard: always reports core events
(**) Option "Protocol" "standard"
(**) Generic Keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Generic Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc104"
(**) Generic Keyboard: XkbModel: "pc104"
(**) Option "XkbLayout" "us"
(**) Generic Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Generic Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)

Mouse works ok.

Thoughts?

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#29 lore raw
Quoted 18 lines · John David Anglin
Quoted 18 lines · John David Anglin
Quoted 17 lines · John David Anglin
Quoted 15 lines · John David Anglin
Quoted 11 lines · Helge Deller
Quoted 5 lines

But when compiling the kernel something is still wrong.
I tried it a few times now, recompiled binutils, the kernel and so on. I'm not 100% sure that I did everything correct, but I still think there is something wrong...

I believe that you are correct but I think we have another unrelated bug. It appears that the unwind data is getting messed up in the link of built-in.o.

It seems the unwind data is being sorted by ld -r.

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

Does the attached patch fix the problem?

Yes, it does :-)

Thanks for testing! I have built a 32-bit kernel with the revised assembler and linker, and the readelf -u output looked good to me. I will install the remaining two changes tonight (the assembler change was installed a couple of days ago).

I did tested the 64bit version now as well.
It looks good too.

Quoted 33 lines

I haven't had a chance to boot the new kernel (waiting for a GCC build to complete). There is a USB issue that appeared on my c3750 with 2.6.30.9 (2.6.30.8 is ok) and 2.6.31.5. Here is the dmesg output from 2.6.31.5:

Linux version 2.6.31.5 (root@hiauly6) (gcc version 4.3.4 (Debian 4.3.4-5) ) #6 Sun Nov 1 14:20:36 EST 2009
unwind_init: start = 0x10524000, end = 0x10559a60, entries = 13734
FP[0] enabled: Rev 1 Model 19
The 32-bit Kernel has started...
...
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
...
usbmon: debugfs is not available
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:0e.2: OHCI Host Controller
ohci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0e.2: irq 1, io mem 0xf4007000
...
usb usb1: configuration #1 chosen from 1 choice
sdb5
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
...
usb 1-1: new low speed USB device using ohci_hcd and address 2
EXT3-fs: mounted filesystem with writeback data mode.
VFS: Mounted root (ext3 filesystem) readonly on device 8:19.
Freeing unused kernel memory: 124k freed
usb 1-1: configuration #1 chosen from 1 choice
usb 1-2: new low speed USB device using ohci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
sysfs: cannot create duplicate filename '/module/usbhid/sections/.text'

Quoted 2 lines
------------[ cut here ]------------
Badness at fs/sysfs/dir.c:487

Yes, this is known.
See here:
http://patchwork.kernel.org/patch/42190/
Would be nice if this could get fixed.

Quoted 35 lines

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001000000000000001111 Not tainted

r00-03  0004000f 10576200 101cb5dc 4edc9000
r04-07  ffffffef 4fbb4288 4edc8a88 00074844
r08-11  4f8db000 00000000 00063000 00000064
r12-15  00000124 00067bbb 104c36a0 00000058
r16-19  00068fc8 00000062 4fbb4148 10576244
r20-23  00002b68 4f16bca0 0027f808 ffffffff
r24-27  ffffffff 00002b68 10576240 1055c2d0
r28-31  0000004e 00000000 4fbb4340 102a0244

sr00-03 00000000 00000000 00000000 00000010
sr04-07 00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101cb5dc 101cb5e0
IIR: 03ffe01f ISR: 00000000 IOR: 00000000
CPU: 0 CR30: 4fbb4000 CR31: ffffffff
ORIG_R28: 00000001
IAOQ[0]: sysfs_add_one+0x8c/0xb4
IAOQ[1]: sysfs_add_one+0x90/0xb4
RP(r2): sysfs_add_one+0x8c/0xb4

Backtrace:
  [<101cadb0>] sysfs_add_file_mode+0x58/0xb4
  [<101cd4b4>] internal_create_group+0x118/0x1dc
  [<10158434>] load_module+0xf14/0x1214

input: Logitech N48 as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-1/1-1:1.0/input/input0 generic-usb 0003:046D:C001.0001: input: USB HID v1.00 Mouse [Logitech N48] on usb-0000:00:0e.2-1/input0
input: SILITEK USB Keyboard and Mouse as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-2/1-2:1.0/input/input1 generic-usb 0003:047B:0002.0002: input: USB HID v1.00 Keyboard [SILITEK USB Keyboard and Mouse] on usb-0000:00:0e.2-2/input0
input: SILITEK USB Keyboard and Mouse as /devices/parisc/10/10:0/pci0000:00/0000:00:0e.2/usb1/1-2/1-2:1.1/input/input2 generic-usb 0003:047B:0002.0003: input: USB HID v1.00 Mouse [SILITEK USB Keyboard and Mouse] on usb-0000:00:0e.2-2/input1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
...

Quoted 3 lines

As you can see, there is a USB mouse and keyboard. Want to see backtrace with new assembler and linker. However, at the least the first part is consistent with the sysfs warning.

I have the same keyboard and mouse attached to my c3000.

Quoted 19 lines

I "upgraded" this system to testing last weekend. The keyboard is broken under X. In gdm/kdm, one has to press a key twice. The Xorg.0.log seems ok:

(**) Option "CoreKeyboard"
(**) Generic Keyboard: always reports core events
(**) Option "Protocol" "standard"
(**) Generic Keyboard: Protocol: standard
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Generic Keyboard: XkbRules: "xorg"
(**) Option "XkbModel" "pc104"
(**) Generic Keyboard: XkbModel: "pc104"
(**) Option "XkbLayout" "us"
(**) Generic Keyboard: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Generic Keyboard: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)

Quoted 2 lines

Mouse works ok.
Thoughts?

No idea, as I only netboot my c3000 and normally don't work in front of those PA boxes. I'll test if I see the same issues...
Did you tried bisecting 2.6.30.8 and 2.6.30.9 ?

Helge

maintainer
#30 lore raw
Quoted 9 lines · Helge Deller
Quoted 3 lines · John David Anglin

sysfs: cannot create duplicate filename '/module/usbhid/sections/.text'

------------[ cut here ]------------
Badness at fs/sysfs/dir.c:487

Yes, this is known.
See here:
http://patchwork.kernel.org/patch/42190/
Would be nice if this could get fixed.

Actually, it is fixed; the patch is upstream as commit 1b364bf438cf337a3818aee77d68c0713f3e1fc4

The patch was designed to fix the panic that occurred. This warn on is coming out of the sysfs code when we try to register a duplicate section name. The panic that followed is what the patch fixed ... but we still get left with the warn on.

James

author maintainer
#31 lore raw
Quoted 11 lines · James Bottomley
Quoted 9 lines · Helge Deller
Quoted 3 lines · John David Anglin

sysfs: cannot create duplicate filename '/module/usbhid/sections/.text'

------------[ cut here ]------------
Badness at fs/sysfs/dir.c:487

Yes, this is known.
See here:
http://patchwork.kernel.org/patch/42190/
Would be nice if this could get fixed.

Quoted 7 lines

Actually, it is fixed; the patch is upstream as commit 1b364bf438cf337a3818aee77d68c0713f3e1fc4

The patch was designed to fix the panic that occurred. This warn on is coming out of the sysfs code when we try to register a duplicate section name. The panic that followed is what the patch fixed ... but we still get left with the warn on.

Yes, the crash is fixed, but still the warning is ugly.
Each time you load any module, this warning is filling up the log.
If you boot via serial console (like me) printing this warning with 9600 baud takes endless time (and you easily get up to 30 times this warning).

Helge

author maintainer
#32 lore raw
In reply to Helge Deller
Quoted 7 lines · Helge Deller
Quoted 4 lines

Thanks for testing! I have built a 32-bit kernel with the revised assembler and linker, and the readelf -u output looked good to me. I will install the remaining two changes tonight (the assembler change was installed a couple of days ago).

I did tested the 64bit version now as well.
It looks good too.

Hi Dave,

sadly I answered too early....
With 64bit kernel I get those unwind warnings again with nearly all kernel modules now:
WARNING: Out of order unwind entry! 0000000000d4ad40 and 0000000000d4ad50

Helge

#33 lore raw
Quoted 4 lines · Helge Deller

sadly I answered too early....
With 64bit kernel I get those unwind warnings again with nearly all kernel modules now:
WARNING: Out of order unwind entry! 0000000000d4ad40 and 0000000000d4ad50

What's readelf say?

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#34 lore raw
Quoted 6 lines · John David Anglin
Quoted 4 lines · Helge Deller

sadly I answered too early....
With 64bit kernel I get those unwind warnings again with nearly all kernel modules now:
WARNING: Out of order unwind entry! 0000000000d4ad40 and 0000000000d4ad50

What's readelf say?

"modprobe libcrc32c" gives in dmesg:
WARNING: Out of order unwind entry! 0020d0e8 and 0020d0f8

[deller@p100 linus-linux-2.6-32bit]$ /opt/cross-hppa-4.4.neu/bin/hppa-linux-readelf -u lib/libcrc32c.ko

Unwind section '.PARISC.unwind' at offset 0x11c contains 3 entries:

<libcrc32c_mod_fini>: [0x0-0x2c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<libcrc32c_mod_init>: [0x0-0x44]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<crc32c>: [0x0-0x6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

#35 lore raw
Quoted 8 lines

Unwind section '.PARISC.unwind' at offset 0x11c contains 3 entries:

<libcrc32c_mod_fini>: [0x0-0x2c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<libcrc32c_mod_init>: [0x0-0x44]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<crc32c>: [0x0-0x6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

What do you see for '.rela.PARISC.unwind'?

I suspect that this is a problem in handling the R_PARISC_SEGREL32 relocations is the kernel loader. The above would be fine if libcrc32c_mod_fini and libcRc32c_mod_init are in different sections (.exit.text and .inti.text).

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#36 lore raw
Quoted 9 lines · John David Anglin
Quoted 8 lines

Unwind section '.PARISC.unwind' at offset 0x11c contains 3 entries:

<libcrc32c_mod_fini>: [0x0-0x2c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<libcrc32c_mod_init>: [0x0-0x44]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<crc32c>: [0x0-0x6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

Quoted 6 lines

What do you see for '.rela.PARISC.unwind'?

I suspect that this is a problem in handling the R_PARISC_SEGREL32 relocations is the kernel loader. The above would be fine if libcrc32c_mod_fini and libcRc32c_mod_init are in different sections (.exit.text and .inti.text).

Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend

00000000  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 0
00000004  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 2c
00000010  00000331 R_PARISC_SEGREL32 00000000   .init.text + 0
00000014  00000331 R_PARISC_SEGREL32 00000000   .init.text + 44
00000020  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 0
00000024  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 6c
#37 lore raw
Quoted 17 lines · John David Anglin
Quoted 9 lines
Quoted 8 lines

Unwind section '.PARISC.unwind' at offset 0x11c contains 3 entries:

<libcrc32c_mod_fini>: [0x0-0x2c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<libcrc32c_mod_init>: [0x0-0x44]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<crc32c>: [0x0-0x6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

Quoted 6 lines

What do you see for '.rela.PARISC.unwind'?

I suspect that this is a problem in handling the R_PARISC_SEGREL32 relocations is the kernel loader. The above would be fine if libcrc32c_mod_fini and libcRc32c_mod_init are in different sections (.exit.text and .inti.text).

Quoted 8 lines

Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:

  Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000000  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 0
00000004  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 2c
00000010  00000331 R_PARISC_SEGREL32 00000000   .init.text + 0
00000014  00000331 R_PARISC_SEGREL32 00000000   .init.text + 44
00000020  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 0
00000024  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 6c

That's exactly what I expected. There's no overlap. The module loader needs to sort the unwind entries after doing the relocations.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#38 lore raw
Quoted 26 lines · John David Anglin
Quoted 17 lines · John David Anglin
Quoted 9 lines
Quoted 8 lines

Unwind section '.PARISC.unwind' at offset 0x11c contains 3 entries:

<libcrc32c_mod_fini>: [0x0-0x2c]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<libcrc32c_mod_init>: [0x0-0x44]
Entry_GR=1 Save_SP Save_RP Total_frame_size=8
<crc32c>: [0x0-0x6c]
Entry_GR=2 Save_SP Save_RP Total_frame_size=8

Quoted 6 lines

What do you see for '.rela.PARISC.unwind'?

I suspect that this is a problem in handling the R_PARISC_SEGREL32 relocations is the kernel loader. The above would be fine if libcrc32c_mod_fini and libcRc32c_mod_init are in different sections (.exit.text and .inti.text).

Quoted 8 lines

Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend

00000000  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 0
00000004  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 2c
00000010  00000331 R_PARISC_SEGREL32 00000000   .init.text + 0
00000014  00000331 R_PARISC_SEGREL32 00000000   .init.text + 44
00000020  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 0
00000024  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 6c
Quoted 2 lines

That's exactly what I expected. There's no overlap. The module loader needs to sort the unwind entries after doing the relocations.

It's already sorting the entries, but creating the relocation is currently a hack.

See top of arch/parisc/kernel/module.c:
* - SEGREL32 handling
* We are not doing SEGREL32 handling correctly. According to the ABI, we
* should do a value offset, like this:
* if (in_init(me, (void *)val))
* val -= (uint32_t)me->module_init;
* else
* val -= (uint32_t)me->module_core;
* However, SEGREL32 is used only for PARISC unwind entries, and we want
* those entries to have an absolute address, and not just an offset.
*

 *      The unwind table mechanism has the ability to specify an offset for
 *      the unwind table; however, because we split off the init functions into
 *      a different piece of memory, it is not possible to do this using a
 *      single offset. Instead, we use the above hack for now.

If we change this, don't we require a binutils update then at the same time from the users?

Helge

#39 lore raw
Quoted 25 lines
Quoted 11 lines
Quoted 8 lines

Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend

00000000  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 0
00000004  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 2c
00000010  00000331 R_PARISC_SEGREL32 00000000   .init.text + 0
00000014  00000331 R_PARISC_SEGREL32 00000000   .init.text + 44
00000020  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 0
00000024  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 6c

That's exactly what I expected. There's no overlap. The module loader needs to sort the unwind entries after doing the relocations.

It's already sorting the entries, but creating the relocation is currently a hack.

See top of arch/parisc/kernel/module.c:
* - SEGREL32 handling
* We are not doing SEGREL32 handling correctly. According to the ABI, we
* should do a value offset, like this:
* if (in_init(me, (void *)val))
* val -= (uint32_t)me->module_init;
* else
* val -= (uint32_t)me->module_core;
* However, SEGREL32 is used only for PARISC unwind entries, and we want
* those entries to have an absolute address, and not just an offset.
*

Quoted 6 lines
  *      The unwind table mechanism has the ability to specify an offset for
  *      the unwind table; however, because we split off the init functions into
  *      a different piece of memory, it is not possible to do this using a
  *      single offset. Instead, we use the above hack for now.

If we change this, don't we require a binutils update then at the same time from the users?

Where does the .exit.text section fit in this scheme? The loader has to appropriately group the sections and determine the section offsets. It would seem that there is a problem with load offset for at least one of the three sections in this module.

Don't think fixing the offsets requires a binutils update. However, the change to using section offsets may have made the problem worse. The binutils update only corrected the issue with overloaded symbols.

Dave

Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
author maintainer
#40 lore raw

Hi Dave,

* John David Anglin <[email protected]>:

Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 8 lines

Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend

00000000  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 0
00000004  00000231 R_PARISC_SEGREL32 00000000   .exit.text + 2c
00000010  00000331 R_PARISC_SEGREL32 00000000   .init.text + 0
00000014  00000331 R_PARISC_SEGREL32 00000000   .init.text + 44
00000020  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 0
00000024  00000431 R_PARISC_SEGREL32 00000000   .text.crc32c + 6c

That's exactly what I expected. There's no overlap. The module loader needs to sort the unwind entries after doing the relocations.

You were right here.

Quoted 1 line
Quoted 1 line

It's already sorting the entries,

and I was to some degree wrong :-)

The parisc module loader as written by Randolph was sorting the unwind entries. But I submitted a wrong patch which replaced the hand-written sort() by the kernel provided sort() function:
http://patchwork.kernel.org/patch/56528/
Due to a bug in the patch a wrong amount of unwind entries were calculated and as such the sort() function didn't sorted all unwind entries.

Below is an updated patch. With this one, all your binutils changes work nicely with 32- and 64-bit kernels and modules.

Kyle, I see you applied my original patch into your "next" tree already:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commit;h=b8d46862d910c3be7c28c627204da968c174aa9a

Do you want me to send you a new patch against your "next" tree instead?

Quoted 5 lines
Quoted 1 line

If we change this, don't we require a binutils update then at the same time from the users?

Don't think fixing the offsets requires a binutils update. However, the change to using section offsets may have made the problem worse. The binutils update only corrected the issue with overloaded symbols.

Yes, a binutils update will just fix user's "out-of-order-unwind-entry" warnings.

Thanks!

Helge

PATCH: parisc: use sort() instead of home-made implementation (v2)

Signed-off-by Helge Deller <[email protected]>
arch/parisc/kernel/unwind.c +7 -1
index 69dad5a..9dbefa8 100644
@@ -13,6 +13,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/kallsyms.h>
+#include <linux/sort.h>
 
 #include <asm/uaccess.h>
 #include <asm/assembly.h>

@@ -115,24 +116,18 @@ unwind_table_init(struct unwind_table *table, const char *name,
 	}
 }
 
+static int cmp_unwind_table_entry(const void *a, const void *b)
+{
+	return ((const struct unwind_table_entry *)a)->region_start
+	     - ((const struct unwind_table_entry *)b)->region_start;
+}
+
 static void
 unwind_table_sort(struct unwind_table_entry *start,
 		  struct unwind_table_entry *finish)
 {
-	struct unwind_table_entry el, *p, *q;