All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.