xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Binutils <binutils@sourceware.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Jeremy Drake <sourceware-bugzilla@jdrake.com>
Subject: Re: ld 2.36 regression linking EFI binary from ELF input
Date: Thu, 18 Feb 2021 15:55:01 +0100	[thread overview]
Message-ID: <8467d4dd-c702-19e2-4511-92f26a7d7b1f@suse.com> (raw)
In-Reply-To: <79812876-b43d-7729-da34-3b4cd1c31f24@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).


      parent reply	other threads:[~2021-02-18 14:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 13:21 ld 2.36 regression linking EFI binary from ELF input with debug info Jan Beulich
2021-02-04 13:34 ` Andreas Schwab
2021-02-04 13:58   ` Jan Beulich
2021-02-18 14:55 ` Jan Beulich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8467d4dd-c702-19e2-4511-92f26a7d7b1f@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=sourceware-bugzilla@jdrake.com \
    --cc=xen-devel@lists.xenproject.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).