>>> On 08.04.16 at 22:50, <konrad.w...@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 21:23, <konrad.w...@oracle.com> wrote:
>> > @@ -57,10 +60,19 @@ SECTIONS
>> > *(.lockprofile.data)
>> > __lock_profile_end = .;
>> > #endif
>> > -
>> > - _erodata = .; /* End of read-only data */
>> > } :text
>> >
>> > +#if defined(BUILD_ID)
>> > + . = ALIGN(4);
>> > + .note : {
>> > + __note_gnu_build_id_start = .;
>> > + *(.note)
>> > + *(.note.*)
>> > + __note_gnu_build_id_end = .;
>> > + } :note :text
>> > +#endif
>>
>> That can't be right: What if any other .note or .note.* section
>> appears for whatever reason? There may be distro specific
>> .note.* sections issued by the compiler...
>
> OK, it is all OK on ELF and on ARM build. But on EFI? The two
> objcopy calls squash the contents of the .note section in the notes.o
> Which means we can include distro specific in EFI (but no in ELF).
>
> The only good solution I can think of is to make the .note section
> on ELF builds to be:
>
> .note : {
> __note_gnu_build_id_start = .;
> *(.note.gnu.build-id)
> __note_gnu_build_id_end = .;
> } :note :text
>
> And that will guarantee that the .note section will only have the
> build-id when ingested by EFI.
>
> And other .notes will be effectively ignored by the xen.lds linker script.
Yes, that's one of the possible routes to go. The other would seem
to be to name the section .note.gnu.build-id instead of just .note.
But that second option can equally well be implemented by whoever
needs a second kind of note propagated in the final image.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
