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
