Out of order unwind entry warning

Out of order unwind entry warning

[Helge Deller]

I started to look into the problem why we get the
> 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

Re: Out of order unwind entry warning

[Kyle McMartin]

On Mon, Oct 26, 2009 at 11:21:20PM +0100, Helge Deller wrote:
> I started to look into the problem why we get the
>> 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

Re: Out of order unwind entry warning

[Randolph Chung]

> 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

Re: Out of order unwind entry warning

[Kyle McMartin]

On Tue, Oct 27, 2009 at 09:50:23AM +0800, Randolph Chung wrote:
>> 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

Re: Out of order unwind entry warning

[John David Anglin]

> 
> I started to look into the problem why we get the
> > 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
> ...

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 10/28/2009 12:19 AM, John David Anglin wrote:
>>
>> I started to look into the problem why we get the
>>> 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
>> ...
>
> 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).

>> <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

Re: Out of order unwind entry warning

[Helge Deller]

Hi Dave,

> On 10/28/2009 12:19 AM, John David Anglin wrote:
>> 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

Re: Out of order unwind entry warning

[John David Anglin]

> Hi Dave,
> 
> > On 10/28/2009 12:19 AM, John David Anglin wrote:
> >> 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.

> 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.

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 10/29/2009 12:10 AM, John David Anglin wrote:
> 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

Re: Out of order unwind entry warning

[Carlos O'Donell]

On Wed, Oct 28, 2009 at 6:00 PM, Helge Deller <deller@gmx.de> wrote:
> 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.

Re: Out of order unwind entry warning

[John David Anglin]

> On 10/28/2009 12:19 AM, John David Anglin wrote:
> >>
> >> I started to look into the problem why we get the
> >>> 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
> >> ...
> >
> > 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).
> 
> >> <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...?

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 10/28/2009 11:18 PM, John David Anglin wrote:
>> On 10/28/2009 12:19 AM, John David Anglin wrote:
>>>>
>>>> I started to look into the problem why we get the
>>>>> 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
>>>> ...
>>>
>>> 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).
>>
>>>> <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...?
>
> 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.

> Does this happen with both 32 and 64 bit kernels?

Yes.

> 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

Re: Out of order unwind entry warning

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

On 10/28/2009 11:43 PM, Helge Deller wrote:
> On 10/28/2009 11:18 PM, John David Anglin wrote:
>>>> 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...

[-- Attachment #2: t1.c --]
[-- Type: text/plain, Size: 152 bytes --]

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();
}

[-- Attachment #3: t2.c --]
[-- Type: text/plain, Size: 30 bytes --]

int f(int x)
{
	return 500;
}

Re: Out of order unwind entry warning

[John David Anglin]

On Wed, 28 Oct 2009, Helge Deller wrote:

> On 10/28/2009 11:43 PM, Helge Deller wrote:
>> On 10/28/2009 11:18 PM, John David Anglin wrote:
>>>>> 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.

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[John David Anglin]

On Wed, 28 Oct 2009, John David Anglin wrote:

> On Wed, 28 Oct 2009, Helge Deller wrote:
> 
> > On 10/28/2009 11:43 PM, Helge Deller wrote:
> >> On 10/28/2009 11:18 PM, John David Anglin wrote:
> >>>>> 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.
> 
> 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.

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Wed, 28 Oct 2009, Helge Deller wrote:

> On 10/28/2009 11:43 PM, Helge Deller wrote:
>> On 10/28/2009 11:18 PM, John David Anglin wrote:
>>>>> 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

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[-- Attachment #2: tc-hppa.c.d --]
[-- Type: text/plain, Size: 1936 bytes --]

Index: config/tc-hppa.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.145
diff -u -3 -p -r1.145 tc-hppa.c
--- config/tc-hppa.c	24 Jul 2009 11:45:00 -0000	1.145
+++ config/tc-hppa.c	29 Oct 2009 18:37:39 -0000
@@ -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);
 

Re: Out of order unwind entry warning

[Helge Deller]

On 10/29/2009 08:16 PM, John David Anglin wrote:
> On Wed, 28 Oct 2009, Helge Deller wrote:
>
>> On 10/28/2009 11:43 PM, Helge Deller wrote:
>>> On 10/28/2009 11:18 PM, John David Anglin wrote:
>>>>>> 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
>
> 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.

> 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

Re: Out of order unwind entry warning

[John David Anglin]

> > 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
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;

Re: Out of order unwind entry warning

[Helge Deller]

On 10/29/2009 10:07 PM, John David Anglin wrote:
>>> 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.

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

Re: Out of order unwind entry warning

[John David Anglin]

> 
> On 10/29/2009 10:07 PM, John David Anglin wrote:
> >>> 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.
> 
> 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.

> 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.

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 10/30/2009 12:35 AM, John David Anglin wrote:
>>
>> On 10/29/2009 10:07 PM, John David Anglin wrote:
>>>>> 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.
>>
>> 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.
>
>> 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.
>
>> 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.

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

Re: Out of order unwind entry warning

[John David Anglin]

> On 10/30/2009 12:35 AM, John David Anglin wrote:
> >>
> >> On 10/29/2009 10:07 PM, John David Anglin wrote:
> >>>>> 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.
> >>
> >> 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.
> >
> >> 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.
> >
> >> 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.
> 
> 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
> --------------------------------------------------------------

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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[John David Anglin]

On Fri, 30 Oct 2009, John David Anglin wrote:

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 10/31/2009 03:19 AM, John David Anglin wrote:
> On Fri, 30 Oct 2009, John David Anglin wrote:
>
>> 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.


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

Re: Out of order unwind entry warning

[John David Anglin]

On Fri, 30 Oct 2009, Helge Deller wrote:

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[John David Anglin]

On Sun, 01 Nov 2009, John David Anglin wrote:

> On Fri, 30 Oct 2009, Helge Deller wrote:
> 
> > 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Sun, 01 Nov 2009, John David Anglin wrote:

> On Sun, 01 Nov 2009, John David Anglin wrote:
> 
> > On Fri, 30 Oct 2009, Helge Deller wrote:
> > 
> > > 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.

Does the attached patch fix the problem?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

[-- Attachment #2: unwind.d --]
[-- Type: text/plain, Size: 1091 bytes --]

Index: elf32-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-hppa.c,v
retrieving revision 1.168
diff -u -3 -p -r1.168 elf32-hppa.c
--- elf32-hppa.c	18 Jun 2009 14:18:28 -0000	1.168
+++ elf32-hppa.c	2 Nov 2009 02:32:05 -0000
@@ -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
diff -u -3 -p -r1.92 elf64-hppa.c
--- elf64-hppa.c	21 May 2009 14:15:49 -0000	1.92
+++ elf64-hppa.c	2 Nov 2009 02:32:05 -0000
@@ -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;

Re: Out of order unwind entry warning

[Helge Deller]

On 11/02/2009 03:34 AM, John David Anglin wrote:
> On Sun, 01 Nov 2009, John David Anglin wrote:
>
>> On Sun, 01 Nov 2009, John David Anglin wrote:
>>
>>> On Fri, 30 Oct 2009, Helge Deller wrote:
>>>
>>>> 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.
>
> 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.

Re: Out of order unwind entry warning

[John David Anglin]

> On 11/02/2009 03:34 AM, John David Anglin wrote:
> > On Sun, 01 Nov 2009, John David Anglin wrote:
> >
> >> On Sun, 01 Nov 2009, John David Anglin wrote:
> >>
> >>> On Fri, 30 Oct 2009, Helge Deller wrote:
> >>>
> >>>> 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.
> >
> > 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 11/02/2009 10:50 PM, John David Anglin wrote:
>> On 11/02/2009 03:34 AM, John David Anglin wrote:
>>> On Sun, 01 Nov 2009, John David Anglin wrote:
>>>
>>>> On Sun, 01 Nov 2009, John David Anglin wrote:
>>>>
>>>>> On Fri, 30 Oct 2009, Helge Deller wrote:
>>>>>
>>>>>> 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.
>>>
>>> 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.

> 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

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

  
>       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 have the same keyboard and mouse attached to my c3000.

  
> 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?

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

Re: Out of order unwind entry warning

[James Bottomley]

On Mon, 2009-11-02 at 23:20 +0100, Helge Deller wrote:
> On 11/02/2009 10:50 PM, John David Anglin wrote:
> > 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

Re: Out of order unwind entry warning

[Helge Deller]

On 11/02/2009 11:31 PM, James Bottomley wrote:
> On Mon, 2009-11-02 at 23:20 +0100, Helge Deller wrote:
>> On 11/02/2009 10:50 PM, John David Anglin wrote:
>>> 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.

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

Re: Out of order unwind entry warning

[Helge Deller]

On 11/02/2009 11:20 PM, Helge Deller wrote:
>> 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

Re: Out of order unwind entry warning

[John David Anglin]

> On 11/02/2009 11:20 PM, Helge Deller wrote:
> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 11/03/2009 12:23 AM, John David Anglin wrote:
>> On 11/02/2009 11:20 PM, Helge Deller wrote:
>> 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

Re: Out of order unwind entry warning

[John David Anglin]

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 11/03/2009 10:36 PM, John David Anglin wrote:
>> 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).

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

Re: Out of order unwind entry warning

[John David Anglin]

> On 11/03/2009 10:36 PM, John David Anglin wrote:
> >> 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).
> 
> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

On 11/03/2009 10:54 PM, John David Anglin wrote:
>> On 11/03/2009 10:36 PM, John David Anglin wrote:
>>>> 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).
>>
>> 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.
  *
  *      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

Re: Out of order unwind entry warning

[John David Anglin]

> >> 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.
>   *
>   *      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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Out of order unwind entry warning

[Helge Deller]

Hi Dave,

* John David Anglin <dave@hiauly1.hia.nrc.ca>:
> > >> 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.

> > 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?


> > 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 <deller@gmx.de>


diff --git a/arch/parisc/kernel/unwind.c b/arch/parisc/kernel/unwind.c
index 69dad5a..9dbefa8 100644
--- a/arch/parisc/kernel/unwind.c
+++ b/arch/parisc/kernel/unwind.c
@@ -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;

Re: Out of order unwind entry warning

[Kyle McMartin]

On Sat, Nov 07, 2009 at 12:07:42AM +0100, Helge Deller wrote:
> 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?

It's ok, I'll just revert that one and apply this one on top of it.

Punch me if I haven't gotten around to this by Monday.

cheers, Kyle