[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] x86/build: use --orphan-handling linker option if available


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 8 Mar 2022 12:15:04 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jLAE1rUwTBXWLXmGNuBMDWnAuUZQaR/HNcqv8pX4qD8=; b=RpSBP6kC5vcpQANt4/yfTKQlcS4vVbdv2ClKhmOXkWX2wB/5eRUJHMk5z4/YoXSex2jg8jUq9GFllrITYHV6bnwS+FgtvFGA69Js9TUlxtZqDReFb5r3/i5w6REj0IcjzuVTWhrE3xWxsikaiHwslaLzWFAA8SZWr07MFnKj4B978BK2sC34jqkIMc1Q7dJKrmkpzv34pD54kTCj6cyHhHiHHh1HTWYp2ERX3l/STgLqmkyJ9Pg38TTde7MVEx0Ie6QMCMggQO8B1e9XSrgBxeKb/FNhfNLMMVWypz/I52AmqFAs2AOjdLF0CDIrDmYovRQkgIi5x1ftaFJOGz/9Gw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eFjvGWtOznCEApT9yoOh9SGx8t7efnjNoDxRf5RrYfzD480sUq3LjyMaf7plyr/PR8UCpp/WCFQk6/UZHyNG1rURnZpxQ95UeZ14AD2E7AasXHwHZQmWrAoRDN681ee2Cs8lfw8qUk7Od7dV7NxLTyOtRrUQtq1hoNHiUxwJb94QCDVpUN+dVi6WxcxcUS8MRGy3ru1gtfuVoeWZFn8gVB8XCbGUrVZ9GZUtBo+9/NuSK2NpvwJ3v4Whis8HObkNDfmLtjNhCHOJ4fQgkLtLvi93mzouoUCNMbNmscEcjWYB/3haJoaoWvmHAcXtYXRyu041HpT/CWeB5HdyNT0EMA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 08 Mar 2022 11:15:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.03.2022 11:12, Roger Pau Monné wrote:
> On Mon, Mar 07, 2022 at 02:53:32PM +0100, Jan Beulich wrote:
>> As was e.g. making necessary 4b7fd8153ddf ("x86: fold sections in final
>> binaries"), arbitrary sections appearing without our linker script
>> placing them explicitly can be a problem. Have the linker make us aware
>> of such sections, so we would know that the script needs adjusting.
>>
>> To deal with the resulting warnings:
>> - Retain .note.* explicitly for ELF, and discard all of them (except the
>>   earlier consumed .note.gnu.build-id) for PE/COFF.
>> - Have explicit statements for .got, .plt, and alike and add assertions
>>   that they're empty. No output sections will be created for these as
>>   long as they remain empty (or else the assertions would cause early
>>   failure anyway).
>> - Collect all .rela.* into a single section, with again an assertion
>>   added for the resulting section to be empty.
>> - Extend the enumerating of .debug_* to ELF. Note that for Clang adding
>>   of .debug_macinfo is necessary. Amend this by its Dwarf5 counterpart,
>>   .debug_macro, then as well (albeit more may need adding for full
>>   coverage).
>>
>> Suggested-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> LGTM, just two questions.

Sure, just that ...

>> @@ -19,6 +26,8 @@ ENTRY(efi_start)
>>  
>>  #define FORMAT "elf64-x86-64"
>>  #define DECL_SECTION(x) #x : AT(ADDR(#x) - __XEN_VIRT_START)
>> +#define DECL_DEBUG(x, a) #x 0 : { *(x) }
>> +#define DECL_DEBUG2(x, y, a) #x 0 : { *(x) *(y) }
> 
> Would it be helpful to place those in a 

... you may have had a 3rd one?

>> @@ -179,6 +188,13 @@ SECTIONS
>>  #endif
>>  #endif
>>  
>> +#ifndef EFI
>> +  /* Retain these just for the purpose of possible analysis tools. */
>> +  DECL_SECTION(.note) {
>> +       *(.note.*)
>> +  } PHDR(note) PHDR(text)
> 
> Wouldn't it be enough to place it in the note program header?
> 
> The buildid note is already placed in .rodata, so any remaining notes
> don't need to be in a LOAD section?

All the notes will be covered by the NOTE phdr. I had this much later
in the script originally, but then the NOTE phdr covered large parts of
.init.*. Clearly that yields invalid notes, which analysis (or simple
dumping) tools wouldn't be happy about. We might be able to add 2nd
NOTE phdr, but mkelf32 assumes exactly 2 phdrs if it finds more than
one, so changes there would likely be needed then (which I'd like to
avoid for the moment). I'm also not sure in how far tools can be
expected to look for multiple NOTE phdrs ...

>> +#endif
>> +
>>    _erodata = .;
>>  
>>    . = ALIGN(SECTION_ALIGN);
>> @@ -266,6 +282,32 @@ SECTIONS
>>         __ctors_end = .;
>>    } PHDR(text)
>>  
>> +#ifndef EFI
>> +  /*
>> +   * With --orphan-sections=warn (or =error) we need to handle certain 
>> linker
>> +   * generated sections. These are all expected to be empty; respective
>> +   * ASSERT()s can be found towards the end of this file.
>> +   */
>> +  DECL_SECTION(.got) {
>> +       *(.got)
>> +  } PHDR(text)
>> +  DECL_SECTION(.got.plt) {
>> +       *(.got.plt)
>> +  } PHDR(text)
>> +  DECL_SECTION(.igot.plt) {
>> +       *(.igot.plt)
>> +  } PHDR(text)
>> +  DECL_SECTION(.iplt) {
>> +       *(.iplt)
>> +  } PHDR(text)
>> +  DECL_SECTION(.plt) {
>> +       *(.plt)
>> +  } PHDR(text)
>> +  DECL_SECTION(.rela) {
>> +       *(.rela.*)
>> +  } PHDR(text)
> 
> Why do you need to explicitly place those in the text program header?

I guess that's largely for consistency with all other directives. With the
assertions that these need to be empty, we might get away without, as long
as no linker would decide to set up another zero-size phdr for them.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.