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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 21:23, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 19:06, <konrad.wilk@xxxxxxxxxx> wrote:
> >> > So that when xen.efi is linked with this build_id.o (in v5, now called 
> >> > notes.o in v6)
> >> > it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end 
> >> > around
> >> > it. I could change for EFI builds the xen.lds.S to be:
> >> > 
> >> >      *(.rodata.*)
> >> > +#if defined(BUILD_ID) && defined(EFI)
> >> > +/*
> >> > + * No mechanism to put an PT_NOTE in the EFI file - so put
> >> > + * it in .data section.
> >> > + */
> >> > +        . = ALIGN(4);
> >> > +
> >> > +       __note_gnu_build_id_start = .;
> >> > +       *(.rodata.note.gnu.build-id)
> >> > +       __note_gnu_build_id_end = .;
> >> > +       *(.note)
> >> > +       *(.note.*)
> >> > +#endif
> >> > 
> >> > But then it differes from the change for !EFI (Which would be naturally
> >> > called .note.gnu.build-id).
> >> 
> >> But that looks to be the right approach, accounting for the
> >> differences between ELF and COFF/PE. And btw., unless you did
> >> changes elsewhere I don't think this inclusion of .note and .note.*
> >> here would have the effect you want it to have.
> > 
> > We don't really have any other .note, which is good.
> > 
> > I tried to feed the linker a notes.o file with .rodata.note
> > and have the efi.lds.S ingest it:
> > 
> >        __note_gnu_build_id_start = .;
> >        *(.rodata.note)
> >        __note_gnu_build_id_end = .;
> > 
> > But it ignored it (no data, and __note_gnu_build_id_start == 
> > __note_gnu_build_id_end)
> 
> I don't think it ignored it - it merely got put in a place you didn't want
> it to be: The earlier *(.rodata.*) consumes it afaict. So perhaps you

Aaah, could very well! Let me try that.
> want to move the notes between .text and .rodata?
> 
> > @@ -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.

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