[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 15:12:50 +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=T2y8xxcOSPcKDydZaw+1PgpNc6QcandMyY0+iEtAYbI=; b=ogO10mR+3UTaZDTawDMgbT+LhkBeBgSBVTpUZkKej4GU5ZWMZiiYaiG8kLZcaEpWXTGIYpkUkIqI9pUcz9O3lvos4kP/CjL1WH/yc4f36tht/LRkyxzcF+UV2av23bEp/eG7IiFahiNXO0FyxPwbrbmh5of8vNQTZ2b31AY+wlgPuM9zQEvEDn2vPGKhnAZhqpIrYPemz2d2uWgwNDv/4b5Bw+B2qoJ33LUS19uTHGv/bQpFolYN7tdrf/rcMqdejE4OZ4/46fhatdpv54k12PQJuI7BOtkx7ay2L7RecXzcsLbHEnN6t8rsuwUEnGp4143yF4TsbIod2JM27cW2ZA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A9S3e4mV/PsLOdyE+71c6fH/F8IlB0bO8uGlwVJWvU6+zBgzUVHNceqZ+EFUyCWgtO5198BRkDMQj0oeb41FJEK1IKUY6+FjtUhgn+fm4K64ueuJ5C2jOxIrMhYPMenf8owFxYicGv8YS8/cKa238vc9AnZXaiVfhSdhfn0CYtbOfLnDdT2aVJuL2rOfcqVFli6iJMY61af/2S6uybyf/XD19qdxsPXjeUv1bE4RQe/SppIlDvU437wXcqv+RPSPL1Rt2b4EADohOfiM9ZSqIMjIQ3rTl07g9ep87/Ne6k6VY4GeFedkjcwFxEsXwPJ8AtkEnUDNXmkrBVtI0kleRg==
  • 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 14:12:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.03.2022 15:07, Roger Pau Monné wrote:
> On Tue, Mar 08, 2022 at 01:34:06PM +0100, Jan Beulich wrote:
>> On 08.03.2022 13:11, Roger Pau Monné wrote:
>>> On Tue, Mar 08, 2022 at 12:15:04PM +0100, Jan Beulich wrote:
>>>> On 08.03.2022 11:12, Roger Pau Monné wrote:
>>>>> On Mon, Mar 07, 2022 at 02:53:32PM +0100, Jan Beulich wrote:
>>>>>> @@ -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 ...
>>>
>>> But if we are adding a .note section now we might as well merge it
>>> with .note.gnu.build-id:
>>>
>>>   DECL_SECTION(.note) {
>>>        __note_gnu_build_id_start = .;
>>>        *(.note.gnu.build-id)
>>>        __note_gnu_build_id_end = .;
>>>        *(.note.*)
>>>   } PHDR(note) PHDR(text)
>>>
>>> And drop the .note.Xen section?
>>
>> In an ideal world we likely could, yes. But do we know for sure that
>> nothing recognizes the Xen notes by section name?
> 
> Wouldn't that be wrong? In the elfnotes.h file it's clearly specified
> that Xen notes live in a PT_NOTE program header and have 'Xen' in the
> name field. There's no requirement of them being in any specific
> section.

True. But ELF also tells us to not go from section names (only), but
to consider type and attribute as well. Yet what do most tools do?

>> .note.gnu.build-id
>> cannot be folded in any event - see the rule for generating note.o,
>> to be used by xen.efi linking in certain cases.
> 
> Right, so we need to keep the .note.gnu.build-id section, but we could
> likely fold .note.Xen into .note I think?
> 
> Or at least add a comment to mention that we don't want to fold
> .note.Xen into .note in case there are tools that search for specific
> Xen notes to be contained in .note.Xen.

I can add such a comment, sure.

Jan




 


Rackspace

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