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 04:49:00PM +0100, Ross Lagerwall wrote:
> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
> >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?
> 
> Yes, that would probably solve the problem.

Sadly no. I stuck the .note right before .bss section and I got:

relink.o: In function `symbols_expand_symbol':
/home/konrad/xen/xen/common/symbols.c:47: undefined reference to `symbols_names'
/home/konrad/xen/xen/common/symbols.c:47:(.text+0x30f40): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `symbols_names'
/home/konrad/xen/xen/common/symbols.c:58: undefined reference to 
`symbols_token_table'
/home/konrad/xen/xen/common/symbols.c:58:(.text+0x30f6e): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `symbols_token_table'


> 
> -- 
> Ross Lagerwall

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