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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.04.16 at 20:47, <konrad.wilk@xxxxxxxxxx> wrote:
> 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'

Well, "before the .bss section" != "last in the binary", but since
we prefer it to be part of r/o data anyway, I guess always
passing the option is reasonable.

Jan


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