From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
"Jason Andryuk" <jandryuk@gmail.com>,
"Stefan Bader" <stefan.bader@canonical.com>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] x86/build32: Discard all orphaned sections
Date: Wed, 13 May 2020 20:14:27 +0100 [thread overview]
Message-ID: <e420b0ab-f0e8-4a31-ef7b-b538a58dd455@citrix.com> (raw)
In-Reply-To: <875d5449-dde0-e675-fb1e-c2b3ed238674@suse.com>
On 13/05/2020 16:15, Jan Beulich wrote:
>>> But it would be really nice if we had a way to
>>> flag the need to play with the linker script. Hence perhaps
>>> on new enough tool chains we indeed may want to make use of
>>> --orphan-handling= ? And then discard just .note and .note.*
>>> here?
>> The only valid option would be =error, but experimenting with that yields
>>
>> ld: error: unplaced orphan section `.comment' from `cmdline.o'
>> ld: error: unplaced orphan section `.note.GNU-stack' from `cmdline.o'
>> ld: error: unplaced orphan section `.note.gnu.property' from `cmdline.o'
>> ld: error: unplaced orphan section `.rel.got' from `cmdline.o'
>> ld: error: unplaced orphan section `.got' from `cmdline.o'
>> ld: error: unplaced orphan section `.got.plt' from `cmdline.o'
>> ld: error: unplaced orphan section `.iplt' from `cmdline.o'
>> ld: error: unplaced orphan section `.rel.iplt' from `cmdline.o'
>> ld: error: unplaced orphan section `.igot.plt' from `cmdline.o'
>>
>> which I think is going to get us massively bogged down in toolchain
>> specifics. I'm not entirely convinced this would be a good move.
> That's ugly indeed; especially the .rel.* sections are worrying to
> appear there.
What is even more curious, most of them don't exist in cmdine.o
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .group GROUP 00000000 000034 000008 04
14 38 4
[ 2] .group GROUP 00000000 00003c 000008 04
14 40 4
[ 3] .text PROGBITS 00000000 000044 00094a 00 AX
0 0 1
[ 4] .rel.text REL 00000000 000e88 0001e8 08 I
14 3 4
[ 5] .data PROGBITS 00000000 00098e 000000 00 WA
0 0 1
[ 6] .bss NOBITS 00000000 00098e 000000 00 WA
0 0 1
[ 7] .rodata PROGBITS 00000000 000990 0000f3 00 A
0 0 4
[ 8] .rel.rodata REL 00000000 001070 000120 08 I
14 7 4
[ 9] .text.__x86.get_pc_thunk.ax PROGBITS 00000000 000a83
000004 00 AXG 0 0 1
[10] .text.__x86.get_pc_thunk.bx PROGBITS 00000000 000a87
000004 00 AXG 0 0 1
[11] .comment PROGBITS 00000000 000a8b 00002d 01 MS
0 0 1
[12] .note.GNU-stack PROGBITS 00000000 000ab8 000000 00
0 0 1
[13] .note.gnu.property NOTE 00000000 000ab8 00001c 00 A
0 0 4
[14] .symtab SYMTAB 00000000 000ad4 000290 10
15 36 4
[15] .strtab STRTAB 00000000 000d64 000124 00
0 0 1
[16] .shstrtab STRTAB 00000000 001190 0000a7 00
0 0 1
I suspect they are inserted by default as part of processing the
relocations, and end up empty.
With =warn rather than =error, we instead get
ld: warning: orphan section `.comment' from `cmdline.o' being placed in
section `.comment'
ld: warning: orphan section `.note.GNU-stack' from `cmdline.o' being
placed in section `.note.GNU-stack'
ld: warning: orphan section `.note.gnu.property' from `cmdline.o' being
placed in section `.note.gnu.property'
ld: warning: orphan section `.rel.got' from `cmdline.o' being placed in
section `.rel.dyn'
ld: warning: orphan section `.got' from `cmdline.o' being placed in
section `.got'
ld: warning: orphan section `.got.plt' from `cmdline.o' being placed in
section `.got.plt'
ld: warning: orphan section `.iplt' from `cmdline.o' being placed in
section `.iplt'
ld: warning: orphan section `.rel.iplt' from `cmdline.o' being placed in
section `.rel.dyn'
ld: warning: orphan section `.igot.plt' from `cmdline.o' being placed in
section `.igot.plt'
and
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .note.gnu.property NOTE 00000000 0000b4 00001c 00 A
0 0 4
[ 2] .text PROGBITS 0000001c 0000d0 000a47 00 WAX
0 0 4
[ 3] .got.plt PROGBITS 00000a64 000b18 00000c 04 WA
0 0 4
[ 4] .comment PROGBITS 00000000 000b24 00002c 01 MS
0 0 1
[ 5] .symtab SYMTAB 00000000 000b50 000230 10
6 31 4
[ 6] .strtab STRTAB 00000000 000d80 000124 00
0 0 1
[ 7] .shstrtab STRTAB 00000000 000ea4 000046 00
0 0 1
in cmdline.lnk, so the .rel.* sections have been dropped overall. I
think the =error logic is simply at an unhelpful position during processing.
> Hence patch as is Acked-by: Jan Beulich <jbeulich@suse.com>
Thanks,
As I say, I have a plan to replace all of this completely when a bit
more of kbuild is in place.
~Andrew
prev parent reply other threads:[~2020-05-13 19:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 19:11 [PATCH] x86/build32: Discard all orphaned sections Andrew Cooper
2020-05-13 2:27 ` Jason Andryuk
2020-05-13 9:13 ` Jan Beulich
2020-05-13 15:00 ` Andrew Cooper
2020-05-13 15:15 ` Jan Beulich
2020-05-13 19:14 ` Andrew Cooper [this message]
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=e420b0ab-f0e8-4a31-ef7b-b538a58dd455@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=jandryuk@gmail.com \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=stefan.bader@canonical.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.