On Sun, 21 Aug 2022 at 12:08, Rebecca Cran <rebe...@bsdio.com> wrote: > > On 8/21/22 03:13, Ard Biesheuvel wrote: > > Which compiler and linker are you using? > I'm using gcc from Ubuntu 22.04: > > > gcc version 11.2.0 (Ubuntu 11.2.0-17ubuntu1) > > GNU ld (GNU Binutils for Ubuntu) 2.38 >
I am failing to reproduce this with both the DEBUG and RELEASE builds of either Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc or Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc using gcc version 12.1.0 (Debian 12.1.0-8) GNU ld (GNU Binutils for Debian) 2.38.90.20220713 and the GCC5 toolchain definition. The NOOPT build of DeveloperBoxMm.dsc does display the symptom (but PlatformStandaloneMmRpmb.dsc fails to build for NOOPT with a different error). The GCC49 toolchain definition fails to build these target in DEBUG and RELEASE mode as well. So this means the issue is likely related to linking PIE executables that were built without LTO, and I suspect that StandaloneMmPkg/Core/StandaloneMmCore.inf in the EDK2 repository currently simply requires LTO when using GCC on AArch64. However, this does not seem to be a fundamental issue, but simply a difference on how LD emits GOT based symbol references at different optimization levels and LTO vs !LTO. GenFw on AArch64 already contains an optimization that converts R_AARCH64_ADR_GOT_PAGE+R_AARCH64_LD64_GOT_LO12_NC pairs into R_AARCH64_ADR_PREL_PG_HI21+R_AARCH64_ADD_ABS_LO12_NC pairs (converting 'load the address of symbol <s> from the GOT' into 'take the address of symbol <s> by adding to the program counter'). Those GOT based relocations never reference the _GLOBAL_OFFSET_TABLE_ symbol directly, though - it simply resolves to a direct reference to the GOT entry that should carry the absolute address after loading. Given that we don't cover the ELF GOT with PE/COFF relocations after conversion, we must relax all GOT based references using the method above (X86_64 does something similar) I suspect we might be able to work around this by adding special treatment for the _GLOBAL_OFFSET_TABLE_ symbol. The fact that some linkers qualify it as absolute is a historical mistake [0], as the location inside the binary of the GOT is obviously dependent on the placement of the binary. Note that the relocation pair that LD emits here is also place relative (R_AARCH64_ADR_PREL_PG_HI21 + R_AARCH64_LD64_GOTPAGE_LO15) which means that we could simply disregard it and end up with the correct address of the GOT entry. *However*, since we don't actually load the GOT with the right values, that wouldn't actually help us, although it would silence the error. This means we'll need special treatment for R_AARCH64_LD64_GOTPAGE_LO15, and convert the LDR instruction at the site into a ADR instruction referring to the symbol directly (instead of to the GOT entry that is supposed to carry its absolute address.) Then, if we also disregard _GLOBAL_OFFSET_TABLE_ references, the resulting binary should run as expected. I'll try to code this up for GenFw in the coming days. [0] https://binutils.sourceware.narkive.com/3VY9kxpd/dynamic-and-global-offset-table -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#92595): https://edk2.groups.io/g/devel/message/92595 Mute This Topic: https://groups.io/mt/93135586/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
