From nobody Fri May 3 05:55:49 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) client-ip=66.175.222.12; envelope-from=bounce+27952+46741+1787277+3901457@groups.io; helo=web01.groups.io; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+46741+1787277+3901457@groups.io; dmarc=fail(p=none dis=none) header.from=linaro.org ARC-Seal: i=1; a=rsa-sha256; t=1567570671; cv=none; d=zoho.com; s=zohoarc; b=iyoYP7mzhKh5KqtdXVdIrI5/Mw7kQQZYlYF7fcXrhVdhvRWPwA4SpFdxe3wOMvPxBFl9QPUpA6TuNc/MeNx7l2c13SwAA/A6tBktXdcpfMNAkVIXgOoX0ie4GOAQhe+8CSjgwwg7gGqZ+Qk3tZ4XEs4Xn1wjsFWpDUtWxJzg6vc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1567570671; h=Cc:Date:From:List-Id:List-Unsubscribe:Message-ID:Reply-To:Sender:Subject:To:ARC-Authentication-Results; bh=JvBFHnzKu/MatfoogBpf3pmfcDWyGQGtRXhCpWwbZQA=; b=YHhLbTbtjXVxY903s9IA7dEWESRwAfHIqh6wKAwKg4iFn3Q8Vew/DOICEWpPaFSalE3cMio1I9SI2qREAfkcix+QqXTFnbtC6K0WRssgS09mLUr4dOYK1FXxJMOkU3mu48GPxUeVBJiw+heSTwNq0dQr8Y9JRhX8iXIvI8LJo+k= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass; spf=pass (zoho.com: domain of groups.io designates 66.175.222.12 as permitted sender) smtp.mailfrom=bounce+27952+46741+1787277+3901457@groups.io; dmarc=fail header.from= (p=none dis=none) header.from= Received: from web01.groups.io (web01.groups.io [66.175.222.12]) by mx.zohomail.com with SMTPS id 1567570671456355.43472446505154; Tue, 3 Sep 2019 21:17:51 -0700 (PDT) Return-Path: X-Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by groups.io with SMTP; Tue, 03 Sep 2019 21:17:50 -0700 X-Received: by mail-pf1-f195.google.com with SMTP id y9so12374531pfl.4 for ; Tue, 03 Sep 2019 21:17:50 -0700 (PDT) X-Gm-Message-State: APjAAAV+4Wde4PuI8l2chmn8ygVwwp3bwE/zD0xgZWIN83uAcvzh9rX0 yGTe74PzCqMHDX+nJf+ORjfCvnRZ+SLeiCZV X-Google-Smtp-Source: APXvYqwI44TtII/uQR/j6yzId6Fb4SHHeDCSxCTOjuGVM6KrzVOlKW6o1Ej4tiQJ61c4/fP/5W9f3A== X-Received: by 2002:a17:90a:8541:: with SMTP id a1mr230089pjw.31.1567570669675; Tue, 03 Sep 2019 21:17:49 -0700 (PDT) X-Received: from e111045-lin.nice.arm.com ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id k64sm36770593pge.65.2019.09.03.21.17.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2019 21:17:48 -0700 (PDT) From: "Ard Biesheuvel" To: devel@edk2.groups.io Cc: leif.lindholm@linaro.org, liming.gao@intel.com, Ard Biesheuvel Subject: [edk2-devel] [PATCH] BaseTools/GenFw AARCH64: fix up GOT based relative relocations Date: Tue, 3 Sep 2019 21:17:33 -0700 Message-Id: <20190904041733.12741-1-ard.biesheuvel@linaro.org> Precedence: Bulk List-Unsubscribe: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ard.biesheuvel@linaro.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=groups.io; q=dns/txt; s=20140610; t=1567570671; bh=1SK3Vkc6Q0/RrSq23SBezKvPr7mf3uha+V+vzrPC3rY=; h=Cc:Date:From:Reply-To:Subject:To; b=dNPIu+Uyh1GSEHVLLHWK9ZGBwOceS4v4qyiMZg/KzT2EZ8Xfg99lI2EUD/sV0j2RQ0A oQra8M29pN1AHMRrgLgTtUF1tpfCfXkyx3DA3RopzH7BpxVCz4LEGD4PJBuVeA/RY8o7u 0+BmCnkExSlG2uUVHR8HoJAwI1Wfik/3dbQ= X-ZohoMail-DKIM: pass (identity @groups.io) Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Reviewed-by: Leif Lindholm --- 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/G= enFw/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 =3D=3D EM_AARCH64) { =20 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_PAG= E below. + // + *(UINT32 *)Targ &=3D 0x3ff; + *(UINT32 *)Targ |=3D 0x91000000 | ((Sym->st_value & 0xfff) << = 10); + break; + + case R_AARCH64_ADR_GOT_PAGE: + // + // This relocation points to the GOT entry that contains the a= bsolute + // address of the symbol we are referring to. Since EDK2 only = uses + // fully linked binaries, we can avoid the indirection, and si= mply + // 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 =3D (Sym->st_value - (Rel->r_offset & ~0xfff)) >> 12; + + *(UINT32 *)Targ &=3D 0x9000001f; + *(UINT32 *)Targ |=3D ((Offset & 0x1ffffc) << (5 - 2)) | ((Offs= et & 0x3) << 29); + + /* fall through */ =20 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; =20 // Decode the ADRP instruction Offset =3D (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 --=20 2.17.1 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46741): https://edk2.groups.io/g/devel/message/46741 Mute This Topic: https://groups.io/mt/33134949/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-