From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=hC/yADIE; spf=pass (domain: linaro.org, ip: 209.85.221.65, mailfrom: leif.lindholm@linaro.org) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by groups.io with SMTP; Wed, 04 Sep 2019 04:49:37 -0700 Received: by mail-wr1-f65.google.com with SMTP id q14so1546070wrm.9 for ; Wed, 04 Sep 2019 04:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YIor1S9lT/1EZIOb6/5ql5pGdWpOITq9x9UwxceVV7Q=; b=hC/yADIEmOL/8Pt/ztBooxdsuYORwMIee7SIMjSagsz3iNJpPgSCrhxSI3GjXaSiy6 zK/9NA68vUcGCh3d6KflsY3UTrjj9BXY6tzLv1O9V0qTtnBlgrgRZInhAsVANjmdjWPd Kemyp3QWBB8lnxbSeJprsAVB1I8g3bUyvlJXNfcav91k8k5r9zs4S/wsT0cd9eV+Bpoi FA2TiAJd2FzRrEL9Xh1h1Y5B6UTIu/heWjAcvqrWGabtPKzWjPpD1B+LTLKXsKGyGlKZ wSDebLBHQL52nqMnZeLtT3PJDEOAau4Lga25LDOz6PqjAOC3LD4RiXhnARnAxQ0d+2aw OcEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YIor1S9lT/1EZIOb6/5ql5pGdWpOITq9x9UwxceVV7Q=; b=UlSR2bXQljgZrbq4A3NWFDEme6S7V1B8apZZPlNYG7x8MS0HKvGkgWYosbxTKyM6yM 8pnFzD+SkdR1ZTdzJB/ujGnmebVhkzB+o/8jrCK2M9pEDyR2MO2Gr8s+sWxZW0ns8gHq um4dxbX9+XQp6itvINW6wklmGEpPGp6LTSVSZondA8f6gVCRw5EFQUNRN5Ey7mpiDcZh zbYZuVRZVbDqDMgzErVUNI8fAOURQP2ZuJ2dR9esinz79QTNUP7SyrEcHxqXvCzB20xf GE3rKovwdo5XohayfAQii08ppZfsU0pEutVFknvUO0bm7/9dOW2WmJW3Dgj0PLgshXHq umZA== X-Gm-Message-State: APjAAAWSKpGminYPD0o+3tU2+hagMxaouRNwYPQ7n8UiaSgWScaDiVql t0F8ZXg2OjVAZ+nvOy1yNlVLag== X-Google-Smtp-Source: APXvYqw22Qf0VLBfzmQ3Q0XpNCbbyrMp9l3muI3JAcvPgFMlPuwCfYk9wM99/BlHEnk1+jJQdsJo6Q== X-Received: by 2002:a5d:4709:: with SMTP id y9mr10133875wrq.129.1567597775546; Wed, 04 Sep 2019 04:49:35 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id a11sm22488292wrx.59.2019.09.04.04.49.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2019 04:49:34 -0700 (PDT) Date: Wed, 4 Sep 2019 12:49:33 +0100 From: "Leif Lindholm" To: Ard Biesheuvel Cc: devel@edk2.groups.io, liming.gao@intel.com Subject: Re: [PATCH] BaseTools/GenFw AARCH64: fix up GOT based relative relocations Message-ID: <20190904114933.GG29255@bivouac.eciton.net> References: <20190904041733.12741-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20190904041733.12741-1-ard.biesheuvel@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 03, 2019 at 09:17:33PM -0700, Ard Biesheuvel wrote: > 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 This is a very neat fix. My only concern is that I am not able to reproduce the issue on my local Buster with clang7 (default). Is it reproducible with clang8? / Leif > --- > 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/GenFw/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 == EM_AARCH64) { > > 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_PAGE below. > + // > + *(UINT32 *)Targ &= 0x3ff; > + *(UINT32 *)Targ |= 0x91000000 | ((Sym->st_value & 0xfff) << 10); > + break; > + > + case R_AARCH64_ADR_GOT_PAGE: > + // > + // This relocation points to the GOT entry that contains the absolute > + // address of the symbol we are referring to. Since EDK2 only uses > + // fully linked binaries, we can avoid the indirection, and simply > + // 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 = (Sym->st_value - (Rel->r_offset & ~0xfff)) >> 12; > + > + *(UINT32 *)Targ &= 0x9000001f; > + *(UINT32 *)Targ |= ((Offset & 0x1ffffc) << (5 - 2)) | ((Offset & 0x3) << 29); > + > + /* fall through */ > > 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; > > // Decode the ADRP instruction > Offset = (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 > -- > 2.17.1 >