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

[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

The problem is the larger default image base, introduced by
514b4e191d5f ("Change the default characteristics of DLLs built
by the linker to more secure settings"). The default linker
script already before this didn't work when specifying a large
enough image base; now it doesn't even work with the default
base address.

The question is what to do with the .debug_* sections. I've
tried a multitude of settings in the linker script, and some
(e.g.

  .debug_info 0 : { *(.debug_info) } :NONE

or [to have a section RVA of zero]

  .debug_info -__image_base__ & 0xffffffff (NOLOAD) : { *(.debug_info) } :NONE

towards the end of the script) even get the linking to succeed,
but any that result in linking success leave the .debug_*
sections first in the section table (which also is the case
when not mentioning the sections at all in the script), which
I consider at least misleading (I didn't try yet whether that
would also cause problems at load time).

The default linker script has this comment

  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section.  Unlike other targets that fake this by putting the
     section VMA at 0, the PE format will not allow it.  */

Since .debug_* are special (by name) in ELF anyway, and we're
talking about ELF input here, wouldn't it make sense to treat
e.g. R_X86_64_32 as section relative when both sections are
.debug_*? Something similar must be happening when the output
is ELF, if the comment above as well as the one next to
BFD_RELOC_32_SECREL is to be trusted?

The section ordering aspect is also why we discard .comment;
in principle, just like for the ELF output, it would seem
desirable to keep the section. (I notice that the default PE
and PE+ linker scripts don't care about .comment at all.) I
wasn't able to figure yet why sections, even when named last
in the linker script, may get placed first.

Jan