[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] x86/build: use --orphan-handling linker option if available
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |