From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web08.6028.1661082256980748921 for ; Sun, 21 Aug 2022 04:44:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pI1+3HMf; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3EC2D60E16 for ; Sun, 21 Aug 2022 11:44:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E7CBC43141 for ; Sun, 21 Aug 2022 11:44:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661082255; bh=vgT5cLvgJTEPuCiMJzzqzxrl90W6D+nLLlQTTiPjbhQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pI1+3HMfGXzsDJIjspRR+ipTmNMQ0iLFjjA5oye/c7xa1wkS0VXHWPAFXsylks+7G 8e7e8jM8Zldrge5MzmIX5mS2sgJdTfw6xsgg6QCws2uf0gR8QBP4ZbXEYlcutXtw4Q ZuXYCXE/lucQYVCqHhEFW1gIM4PsPCS6/YjN+THwt6ZvlDznAs+Mm5U/Zd6qE4gXGH NRTdvUMOW9BzVdUqtskekD1oAgYIq+zFfTAa0NO/pAjxoeKoA2xDrWbP/667jyUEDz 0OvQiZ/gPwav7U+a65Esa0/STY0NxE6z1SVPojbh19RriyV6LdZBepqwf3hMQF3FgE IIpkKQrOrLJQQ== Received: by mail-wm1-f51.google.com with SMTP id bd26-20020a05600c1f1a00b003a5e82a6474so4621053wmb.4 for ; Sun, 21 Aug 2022 04:44:15 -0700 (PDT) X-Gm-Message-State: ACgBeo1bt43O96JYJ7ZJnGF1a/N5iGOBjkwwukP1RxE7CNvXzn3hIMBh fpVCJgL8zAxcDGdZnvc1Px53jgZpGt8ggeWB6f8= X-Google-Smtp-Source: AA6agR7KfMeiCAfTtXtem0aC8Bp4mWfurMwgUVqaaqNrAhdm/N12hvsT2mzGBm2T/I0+YIdwon4/nmRB7gZlUHDPHHk= X-Received: by 2002:a05:600c:384f:b0:3a6:603c:4338 with SMTP id s15-20020a05600c384f00b003a6603c4338mr1279245wmr.192.1661082253336; Sun, 21 Aug 2022 04:44:13 -0700 (PDT) MIME-Version: 1.0 References: <5401edf1-a6a5-9193-2be5-cff2cf64081f@bsdio.com> <1df1ad19-65b4-21e0-a14c-45f38ed55941@bsdio.com> In-Reply-To: <1df1ad19-65b4-21e0-a14c-45f38ed55941@bsdio.com> From: "Ard Biesheuvel" Date: Sun, 21 Aug 2022 13:44:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_) To: Rebecca Cran , Sami Mujawar , Jiewen Yao Cc: devel@edk2.groups.io, "Kinney, Michael D" , Leif Lindholm , Pedro Falcato , =?UTF-8?Q?Marvin_H=C3=A4user?= Content-Type: text/plain; charset="UTF-8" On Sun, 21 Aug 2022 at 12:08, Rebecca Cran 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 from the GOT' into 'take the address of symbol 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