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

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids



On Fri, Apr 08, 2016 at 03:11:17PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 22:50, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 21:23, <konrad.wilk@xxxxxxxxxx> 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.

Hehe.
> But that second option can equally well be implemented by whoever
> needs a second kind of note propagated in the final image.

/me nods.

OK, so .note.gnu.build-id is what I am going with.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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