From: Helge Deller <deller@gmx.de>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: linux-parisc@vger.kernel.org, carlos@systemhalted.org,
randolph@tausq.org
Subject: Re: Out of order unwind entry warning
Date: Wed, 28 Oct 2009 22:42:20 +0100 [thread overview]
Message-ID: <4AE8BABC.80108@gmx.de> (raw)
In-Reply-To: <20091027231909.74AEF4E0B@hiauly1.hia.nrc.ca>
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
next prev parent reply other threads:[~2009-10-28 21:42 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-26 22:21 Out of order unwind entry warning Helge Deller
2009-10-26 23:41 ` Kyle McMartin
2009-10-27 1:50 ` Randolph Chung
2009-10-27 2:24 ` Kyle McMartin
2009-10-27 23:19 ` John David Anglin
2009-10-28 21:42 ` Helge Deller [this message]
2009-10-28 22:00 ` Helge Deller
2009-10-28 23:10 ` John David Anglin
2009-10-29 20:51 ` Helge Deller
2009-10-29 13:20 ` Carlos O'Donell
2009-10-28 22:18 ` John David Anglin
2009-10-28 22:43 ` Helge Deller
2009-10-28 22:59 ` Helge Deller
2009-10-29 2:11 ` John David Anglin
2009-10-29 16:38 ` John David Anglin
2009-10-29 19:16 ` John David Anglin
2009-10-29 20:46 ` Helge Deller
2009-10-29 21:07 ` John David Anglin
2009-10-29 22:22 ` Helge Deller
2009-10-29 23:35 ` John David Anglin
2009-10-30 22:47 ` Helge Deller
2009-10-31 0:41 ` John David Anglin
2009-10-31 2:19 ` John David Anglin
2009-10-31 7:39 ` Helge Deller
2009-11-01 23:16 ` John David Anglin
2009-11-02 1:40 ` John David Anglin
2009-11-02 2:34 ` John David Anglin
2009-11-02 21:02 ` Helge Deller
2009-11-02 21:50 ` John David Anglin
2009-11-02 22:20 ` Helge Deller
2009-11-02 22:31 ` James Bottomley
2009-11-02 22:43 ` Helge Deller
2009-11-02 22:52 ` Helge Deller
2009-11-02 23:23 ` John David Anglin
2009-11-03 21:10 ` Helge Deller
2009-11-03 21:36 ` John David Anglin
2009-11-03 21:43 ` Helge Deller
2009-11-03 21:54 ` John David Anglin
2009-11-03 22:04 ` Helge Deller
2009-11-04 0:57 ` John David Anglin
2009-11-06 23:07 ` Helge Deller
2009-11-07 20:11 ` Kyle McMartin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE8BABC.80108@gmx.de \
--to=deller@gmx.de \
--cc=carlos@systemhalted.org \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=linux-parisc@vger.kernel.org \
--cc=randolph@tausq.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox