[edk2-devel] [PATCH] BaseTools/GenFw AARCH64: fix up GOT based relative relocations
Leif Lindholm
leif.lindholm at linaro.org
Wed Sep 4 11:49:33 UTC 2019
On Tue, Sep 03, 2019 at 09:17:33PM -0700, Ard Biesheuvel wrote:
> We take great care to avoid GOT based relocations in EDK2 executables,
> primarily because they are pointless - we don't care about things like
> the CoW footprint or relocations that target read-only sections, and so
> GOT entries only bloat the binary.
>
> However, in some cases (e.g., when building the relocatable PrePi SEC
> module in ArmVirtPkg with the CLANG38 toolchain), we may end up with
> some GOT based relocations nonetheless, which break the build since
> GenFw does not know how to deal with them.
>
> The relocations emitted in this case are ADRP/LDR instruction pairs
> that are annotated as GOT based, which means that it is the linker's
> job to emit the GOT entry and tag it with an appropriate dynamic
> relocation that ensures that the correct absolute value is stored into
> the GOT entry when the executable is loaded. This dynamic relocation
> not visible to GenFw, and so populating the PE/COFF relocation section
> for these entries is non-trivial.
>
> Since each ADRP/LDR pair refers to a single symbol that is local to the
> binary (given that shared libraries are not supported), we can actually
> convert the ADRP/LDR pair into an ADRP/ADD pair that produces the symbol
> address directly rather than loading it from memory. This leaves the
> GOT entry in the binary, but since it is now unused, it is no longer
> necessary to emit a PE/COFF relocation entry for it.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
This is a very neat fix. My only concern is that I am not able to
reproduce the issue on my local Buster with clang7 (default). Is it
reproducible with clang8?
/
Leif
> ---
> BaseTools/Source/C/GenFw/Elf64Convert.c | 28 +++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
> index 3d6319c821e9..d574300ac4fe 100644
> --- a/BaseTools/Source/C/GenFw/Elf64Convert.c
> +++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
> @@ -1017,6 +1017,31 @@ WriteSections64 (
> } else if (mEhdr->e_machine == EM_AARCH64) {
>
> switch (ELF_R_TYPE(Rel->r_info)) {
> + INT64 Offset;
> +
> + case R_AARCH64_LD64_GOT_LO12_NC:
> + //
> + // Convert into an ADD instruction - see R_AARCH64_ADR_GOT_PAGE below.
> + //
> + *(UINT32 *)Targ &= 0x3ff;
> + *(UINT32 *)Targ |= 0x91000000 | ((Sym->st_value & 0xfff) << 10);
> + break;
> +
> + case R_AARCH64_ADR_GOT_PAGE:
> + //
> + // This relocation points to the GOT entry that contains the absolute
> + // address of the symbol we are referring to. Since EDK2 only uses
> + // fully linked binaries, we can avoid the indirection, and simply
> + // refer to the symbol directly. This implies having to patch the
> + // subsequent LDR instruction (covered by a R_AARCH64_LD64_GOT_LO12_NC
> + // relocation) into an ADD instruction - this is handled above.
> + //
> + Offset = (Sym->st_value - (Rel->r_offset & ~0xfff)) >> 12;
> +
> + *(UINT32 *)Targ &= 0x9000001f;
> + *(UINT32 *)Targ |= ((Offset & 0x1ffffc) << (5 - 2)) | ((Offset & 0x3) << 29);
> +
> + /* fall through */
>
> case R_AARCH64_ADR_PREL_PG_HI21:
> //
> @@ -1037,7 +1062,6 @@ WriteSections64 (
> // Attempt to convert the ADRP into an ADR instruction.
> // This is only possible if the symbol is within +/- 1 MB.
> //
> - INT64 Offset;
>
> // Decode the ADRP instruction
> Offset = (INT32)((*(UINT32 *)Targ & 0xffffe0) << 8);
> @@ -1212,6 +1236,8 @@ WriteRelocations64 (
> case R_AARCH64_LDST32_ABS_LO12_NC:
> case R_AARCH64_LDST64_ABS_LO12_NC:
> case R_AARCH64_LDST128_ABS_LO12_NC:
> + case R_AARCH64_ADR_GOT_PAGE:
> + case R_AARCH64_LD64_GOT_LO12_NC:
> //
> // No fixups are required for relative relocations, provided that
> // the relative offsets between sections have been preserved in
> --
> 2.17.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#46803): https://edk2.groups.io/g/devel/message/46803
Mute This Topic: https://groups.io/mt/33134949/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list