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 16:00:14 +0100	[thread overview]
Message-ID: <e11b2b5b-5504-f2a3-f1d8-986bc97a4b78@citrix.com> (raw)
In-Reply-To: <a1d1135a-8f9c-81c3-5fc8-bbc3787ebd0f@suse.com>

On 13/05/2020 10:13, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe.
>
> On 12.05.2020 21:11, Andrew Cooper wrote:
>> @@ -47,6 +47,14 @@ SECTIONS
>>           *
>>           * Please check build32.mk for more details.
>>           */
>> -        /* *(.got.plt) */
>> +        *(.got.plt)
>> +  }
>> +
>> +  /DISCARD/ : {
>> +        /*
>> +         * Discard everything else, to prevent linkers from putting
>> +         * orphaned sections ahead of .text, which needs to be first.
>> +         */
>> +        *(*)
>>    }
>>  }
> To be honest I'm not sure if this isn't going too far. Much
> depends on what would happen if a new real section appeared
> that needs retaining.

Anything which is important enough will result in a linker error.

> Granted the linker may then once again
> put it at the beginning of the image, and we'll be screwed
> again, just like we'll be screwed if a section gets discarded
> by mistake.

This way is more likely to result in a build failure than an inability
to boot the resulting build of Xen.

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

~Andrew


  reply	other threads:[~2020-05-13 15:00 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 [this message]
2020-05-13 15:15     ` Jan Beulich
2020-05-13 19:14       ` Andrew Cooper

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=e11b2b5b-5504-f2a3-f1d8-986bc97a4b78@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.