BaseTools/GenFw AARCH64: Convert more types of explicit GOT references

Rebecca reports that builds of AArch64 DSCs that involve PIE linking
when using ELF based toolchains are failing in some cases, resulting in
an error message like

  bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
  unsupported symbol type.  For example, absolute and undefined symbols
  are not supported.

The reason turns out to be that, while GenFw does carry some logic to
convert GOT based symbol references into direct ones (which is always
possible given that our ELF to PE/COFF conversion only supports fully
linked executables), it does not support all possible combinations of
relocations that the linker may emit to load symbol addresses from the
GOT.

In particular, when performing a non-LTO link on object code built with
GCC using -fpie, we may end up with GOT based references such as the one
below, where the address of the GOT itself is taken, and the offset of
the symbol in the GOT is reflected in the immediate offset of the
subsequent LDR instruction.

  838:   adrp    x0, 16000
  838: R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_
  83c:   ldr     x0, [x0, #2536]
  83c: R_AARCH64_LD64_GOTPAGE_LO15        _gPcd_BinaryPatch_PcdFdBaseAddress

The reason that we omit GOT based symbol references when performing ELF to
PE/COFF conversion is that the GOT is not described by static ELF
relocations, which means that the ELF file lacks the metadata to
generate the PE/COFF relocations covering the GOT table in the PE/COFF
executable. Given that none of the usual motivations for using a GOT
(copy on write footprint, shared libraries) apply to EFI executables in
the first place, the easiest way around this is to convert all GOT based
symbol address loads to PC relative ADR/ADRP instructions.

So implement this handling for R_AARCH64_LD64_GOTPAGE_LO15 and
R_AARCH64_LD64_GOTOFF_LO15 relocations as well, and turn the LDR
instructions in question into ADR instructions that generate the
address immediately.

This leaves the reference to _GLOBAL_OFFSET_TABLE_ itself, which is what
generated the error to begin with. Considering that this symbol is never
referenced (i.e., it doesn't appear anywhere in the code) and is only
meaningful in combination with R_*_GOT_* based relocations that follow
it, we can just disregard any references to it entirely, given that we
convert all of those followup relocations into direct references.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Leif Lindholm <quic_llindhol@quicinc.com>
Acked-by: Bob Feng <bob.c.feng@intel.com>

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 35e96dd05bc26f7212d0f80af1ecb998bcb993dd..ca3c8f8bee8c346825dc5003572a3a8fd4a7b495 100644 (file)
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -1305,6 +1305,22 @@ WriteSections64 (
         Elf_Shdr *SymShdr;\r
         UINT8    *Targ;\r
 \r
+        //\r
+        // The _GLOBAL_OFFSET_TABLE_ symbol is not actually an absolute symbol,\r
+        // but carries the SHN_ABS section index for historical reasons.\r
+        // It must be accompanied by a R_*_GOT_* type relocation on a\r
+        // subsequent instruction, which we handle below, specifically to avoid\r
+        // the GOT indirection, and to refer to the symbol directly. This means\r
+        // we can simply disregard direct references to the GOT symbol itself,\r
+        // as the resulting value will never be used.\r
+        //\r
+        if (Sym->st_shndx == SHN_ABS) {\r
+          const UINT8 *SymName = GetSymName (Sym);\r
+          if (strcmp ((CHAR8 *)SymName, "_GLOBAL_OFFSET_TABLE_") == 0) {\r
+            continue;\r
+          }\r
+        }\r
+\r
         //\r
         // Check section header index found in symbol table and get the section\r
         // header location.\r
@@ -1448,6 +1464,23 @@ WriteSections64 (
           switch (ELF_R_TYPE(Rel->r_info)) {\r
             INT64 Offset;\r
 \r
+          case R_AARCH64_LD64_GOTOFF_LO15:\r
+          case R_AARCH64_LD64_GOTPAGE_LO15:\r
+            //\r
+            // Convert into an ADR instruction that refers to the symbol directly.\r
+            //\r
+            Offset = Sym->st_value - Rel->r_offset;\r
+\r
+            *(UINT32 *)Targ &= 0x1000001f;\r
+            *(UINT32 *)Targ |= ((Offset & 0x1ffffc) << (5 - 2)) | ((Offset & 0x3) << 29);\r
+\r
+            if (Offset < -0x100000 || Offset > 0xfffff) {\r
+              Error (NULL, 0, 3000, "Invalid", "WriteSections64(): %s failed to relax GOT based symbol reference - image is too big (>1 MiB).",\r
+                mInImageName);\r
+              break;\r
+            }\r
+            break;\r
+\r
           case R_AARCH64_LD64_GOT_LO12_NC:\r
             //\r
             // Convert into an ADD instruction - see R_AARCH64_ADR_GOT_PAGE below.\r
@@ -1686,6 +1719,8 @@ WriteRelocations64 (
             case R_AARCH64_LDST128_ABS_LO12_NC:\r
             case R_AARCH64_ADR_GOT_PAGE:\r
             case R_AARCH64_LD64_GOT_LO12_NC:\r
+            case R_AARCH64_LD64_GOTOFF_LO15:\r
+            case R_AARCH64_LD64_GOTPAGE_LO15:\r
               //\r
               // No fixups are required for relative relocations, provided that\r
               // the relative offsets between sections have been preserved in\r