[edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Ard Biesheuvel]

On Sun, 21 Aug 2022 at 12:08, Rebecca Cran <rebecca at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-