Re: ld 2.36 regression linking EFI binary from ELF input

[Jan Beulich <jbeulich@suse.com>]

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