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

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

On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote:
> > The version of ld that first implemented --build-id is v2.18.
> > Hence we check for that or later version - if older version
> > found we do not build the hypervisor with the build-id
> > (and the return code is -ENODATA for xen_build_id() call).
> 
> This appears to be stale.
> 
> > The EFI binary is more complicated. Having any non-recognizable
> > sections (.note, .data.note, etc) causes the boot to hang.
> > Moving the .note in the .data section makes it work. It is also
> > worth noting that the PE/COFF does not have any "comment"
> > sections to the author.
> 
> I'm afraid this is too vague: What exactly is happening there? And
> is this due to binutils doing something wrong, or an issue with the
> firmware on the box you've tried? While the placement of .note is
> not really a big deal, any unusual placement needs a source
> comment attached explaining the whys, to prevent people down
> the road moving the section back into the "expected" place. But
> see also below.

I will have to dig in this more. I know I tried it on TianoCore but
that seems to have some other issues at the moment so I will
try it out on real hardware.
> 
> > Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> > symbol offsets don't changes (which means we have multiple binary
> > ids - except that the last one is the final one). Without this change,
> > the symbol table embedded in Xen are incorrect - some of the values it
> > contains are offset by the size of the included build id.
> > This obviously causes problems when resolving symbols.
> 
> Would this also be a problem if you place the notes segment/section
> last in the binary?

I am not sure. Ross, you are the one who observed this?
> > +build_id.o: $(TARGET)-syms
> > +   $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
> 
> Considering your xen.lds.S changes, won't this potentially copy quite
> a bit more than just the build ID (i.e. all notes)? This may be okay, and
> may be even intended, but then the generate file's name should
> reflect this to not misguide people.


I renamed it notes.o

> 
> > +   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +           --rename-section=.data=.note.gnu.build-id -S $@.bin $@
> 
> Since you put the notes into .rodata anyway, why name the
> section .note.*? Just name it .rodata.*, avoiding to mislead
> others who also think that a section's name has much of a
> meaning.

I thought that somebody during review asked for it to be called .note?
But I will dig in this next week.

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