public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel@lists.01.org, lersek@redhat.com,
	Bob Feng <bob.c.feng@intel.com>,
	Liming Gao <liming.gao@intel.com>
Subject: Re: [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations
Date: Tue, 11 Dec 2018 09:53:52 +0000	[thread overview]
Message-ID: <20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net> (raw)
In-Reply-To: <20181211093715.6048-1-ard.biesheuvel@linaro.org>

On Tue, Dec 11, 2018 at 10:37:15AM +0100, Ard Biesheuvel wrote:
> We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion
> routines, under the assumption that relative relocations are fine as
> long as the section layout is the same between ELF and PE/COFF.
> 
> However, as is the case with any proxy generating relocation, it is
> up to the linker to emit an entry in the GOT table and populate it
> with the correct absolute address, which should also be fixed up at
> PE/COFF load time. Unfortunately, the relocations covering the GOT
> section are not emitted into the static relocation sections processed
> by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE
> relocation, and so GenFw fails to emit the correct PE/COFF relocation
> data for GOT entries.
> 
> Since GOT indirection is pointless anyway for PE/COFF modules running
> in UEFI context, let's just drop the references to R_ARM_GOT_PREL from
> GenFw, resulting in a build time failure rather than a runtime failure
> if such relocations do occur.
> 
> Cc: Bob Feng <bob.c.feng@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>

Ouch. This sounds like the best move for now. But how do we deal with
builds that actually break?

> ---
> 
> Without this patch, CLANG38 builds of ArmVirtQemuKernel-ARM (in LTO mode)
> succeed, but the resulting binaries are broken. This is due to the fact that
> the PIE linker running in LTO mode insists on emitting GOT based relocations,
> while we don't have the code to fix up the contents of the GOT. This change
> puts it in line with the AARCH64 build of the same platform/toolchains,
> which chokes on GOT based relocations as well. Since the use of the PIE
> linker is a peculiarity of ArmVirtQemuKernel/ArmVirtXen, and the fact that
> it is impossible to prevent the linker from emitting GOT based relocations,
> let's not go out of our way to fix it in the tools, but just drop CLANG38
> support from those platforms.
> 
>  BaseTools/Source/C/GenFw/Elf32Convert.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c b/BaseTools/Source/C/GenFw/Elf32Convert.c
> index 3d7de6d5c123..23e8065756e6 100644
> --- a/BaseTools/Source/C/GenFw/Elf32Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c
> @@ -837,7 +837,6 @@ WriteSections32 (
>            case R_ARM_LDC_PC_G0:
>            case R_ARM_LDC_PC_G1:
>            case R_ARM_LDC_PC_G2:
> -          case R_ARM_GOT_PREL:
>            case R_ARM_THM_JUMP11:
>            case R_ARM_THM_JUMP8:
>            case R_ARM_TLS_GD32:
> @@ -964,7 +963,6 @@ WriteRelocations32 (
>              case R_ARM_LDC_PC_G0:
>              case R_ARM_LDC_PC_G1:
>              case R_ARM_LDC_PC_G2:
> -            case R_ARM_GOT_PREL:
>              case R_ARM_THM_JUMP11:
>              case R_ARM_THM_JUMP8:
>              case R_ARM_TLS_GD32:
> -- 
> 2.19.2
> 


  reply	other threads:[~2018-12-11  9:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11  9:37 [PATCH] BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations Ard Biesheuvel
2018-12-11  9:53 ` Leif Lindholm [this message]
2018-12-11 11:19   ` Ard Biesheuvel
2018-12-11 11:21     ` Ard Biesheuvel
2018-12-11 13:40       ` Gao, Liming
2018-12-11 13:45         ` Ard Biesheuvel
2018-12-12  0:24           ` Gao, Liming
2018-12-12  7:38             ` Ard Biesheuvel
2018-12-11 15:57 ` Laszlo Ersek

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20181211095352.7bpfscgu3e3ne42m@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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