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 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

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

[Jeremy Drake]

On Tue, 16 Feb 2021, Jan Beulich wrote:

> 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.
> >
>
> 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.
>

I don't think this issue is exclusive to EFI.  I have seen one or two
reports of this on the msys2 project, the only one I can remember/track
down at the moment is
https://github.com/msys2/MINGW-packages/issues/7023#issuecomment-774672411

A similar unsolved issue happens with undefined weak symbols, reported as
https://sourceware.org/bugzilla/show_bug.cgi?id=26659

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

[Jan Beulich]

On 17.02.2021 06:56, Jeremy Drake wrote:
> On Tue, 16 Feb 2021, Jan Beulich wrote:
> 
>> 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.
>>>
>>
>> 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.
>>
> 
> I don't think this issue is exclusive to EFI.

And indeed I didn't mean to imply anything like this. It's just
the case where we've run into the issue, and where we need it
fixed.

>  I have seen one or two
> reports of this on the msys2 project, the only one I can remember/track
> down at the moment is
> https://github.com/msys2/MINGW-packages/issues/7023#issuecomment-774672411

This looks different - IMAGE_REL_AMD64_SECREL overflowing would
either imply huge debug info (more than 2Gb / 4Gb depending on
whether the relocated item is considered signed or unsigned) or
a bug in the processing of the relocation itself. Generally the
ability to use section-relative relocations is specifically a
"luxury" most architectures don't have when using ELF objects.

> A similar unsolved issue happens with undefined weak symbols, reported as
> https://sourceware.org/bugzilla/show_bug.cgi?id=26659

Yes, I'm aware of this, but I expect this to be more difficult
to address, because it affects the actual code/data of an image,
not just its debug info (i.e. getting it wrong has more severe
consequences).

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