ld 2.36 regression linking EFI binary from ELF input with debug info

ld 2.36 regression linking EFI binary from ELF input with debug info

[Jan Beulich]

Hello,

the Xen project hypervisor build system includes building the
hypervisor binary as an EFI application, as an option (i.e.
as long as the tool chain supports this). Already when probing
the linker we now suddenly get several "relocation truncated
to fit:R_X86_64_32 against `.debug_...'" errors. I have not
had  the time to figure out what exactly broke this, and I'm
sending this mail in the hope that it may ring a bell for
someone.

For reference, the probing is as simple as

$(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o

As was to be expected, the errors disappear with -S, but that's
an option only for the probing, not for the actual linking of
the binary.

Thanks for pointers (or better yet, a fix),
Jan

Re: ld 2.36 regression linking EFI binary from ELF input with debug info

[Andreas Schwab]

On Feb 04 2021, Jan Beulich via Binutils wrote:

> For reference, the probing is as simple as
>
> $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o
>
> As was to be expected, the errors disappear with -S, but that's
> an option only for the probing, not for the actual linking of
> the binary.
>
> Thanks for pointers (or better yet, a fix),

Does it work to link to ELF and use objcopy to convert to PE?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: ld 2.36 regression linking EFI binary from ELF input with debug info

[Jan Beulich]

On 04.02.2021 14:34, Andreas Schwab wrote:
> On Feb 04 2021, Jan Beulich via Binutils wrote:
> 
>> For reference, the probing is as simple as
>>
>> $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o
>>
>> As was to be expected, the errors disappear with -S, but that's
>> an option only for the probing, not for the actual linking of
>> the binary.
>>
>> Thanks for pointers (or better yet, a fix),
> 
> Does it work to link to ELF and use objcopy to convert to PE?

Looks like so, albeit I can't easily tell whether the output would
actually be usable in any way. I also don't think this could be an
option for our build process.

Jan

Re: ld 2.36 regression linking EFI binary from ELF input

[Jan Beulich]

On 04.02.2021 14:21, Jan Beulich via Binutils wrote:
> the Xen project hypervisor build system includes building the
> hypervisor binary as an EFI application, as an option (i.e.
> as long as the tool chain supports this). Already when probing
> the linker we now suddenly get several "relocation truncated
> to fit:R_X86_64_32 against `.debug_...'" errors. I have not
> had  the time to figure out what exactly broke this, and I'm
> sending this mail in the hope that it may ring a bell for
> someone.
> 
> For reference, the probing is as simple as
> 
> $(LD) -mi386pep --subsystem=10 -o efi/check.efi efi/check.o
> 
> As was to be expected, the errors disappear with -S, but that's
> an option only for the probing, not for the actual linking of
> the binary.

Actually, that was just the easily visible problem. There's a
worse one, again resulting from 514b4e191d5f ("Change the
default characteristics of DLLs built by the linker to more
secure settings"): Prior to this a .reloc section would not
have been created by ld for executables. To work around this
we've been hand-crafting relocations (by linking the image at
two different base addresses and working out the delta). Now
that ld does this by default, we get two base relocations for
every field that needs relocating. Which obviously isn't
going to work.

We also can't easily use ld's way of populating .reloc, as
it's buggy (I'll send separate mail about that) and apart
from this the resulting relocations differ subtly for the
pre-populated page tables (using physical addresses, not
virtual ones) that the binary contains.

The immediate workaround at our end is therefore going to be
to use --disable-reloc-section when available, but I have to
admit that this is far worse breakage than I would have
expected from a single-step binutils version increment. I
wouldn't be surprised if Cygwin / MingW (or users thereof,
when they are creating their own programs on top) aren't
similarly affected. Luckily(?) the Windows loader looks to
fall back to ignoring .relocs when it encounters an error
processing one of the relocations, at least for executables
(for DLLs this may not be an option).

Jan