From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by mx.groups.io with SMTP id smtpd.web10.7117.1573200030938824499 for ; Fri, 08 Nov 2019 00:00:31 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=r6I5l9d9; spf=pass (domain: linaro.org, ip: 209.85.128.65, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f65.google.com with SMTP id a17so5929042wmb.0 for ; Fri, 08 Nov 2019 00:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Qykf+o9ip7h2M4ihwSzUNElQRP8AUhrz4pRdV+iT8w=; b=r6I5l9d9jQ1n3zhLtnN+9kFGGpHCZegT3EsjfoM64k2Ij5aK/nYZ7BynBygJZAXWBv y0q8qs5AbGjFSfHHMM8kEvVncRi+cTNNytIgCn5Qf6F5B+4uYptkdj20xTFdHOS1qa1M vDzRCZh8TS/B6wO7EbTUDtm48wIZGNz2KCcFs3+N2qm8dEmGyrPCw3dUQQ0vThoiq7p9 mzcw+1hOxf47rCx/dDQVZvMx+JvRtv2Wp9zp9V76O32jXMxPgSC1OG42dgwdTwm7gCxH SogyXp5fSMt+cIpZTzLPJ/oPDTupoKb8lHa3gYFrWXNmafc+SibFVFFzSeleASSlRIl+ 0oBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Qykf+o9ip7h2M4ihwSzUNElQRP8AUhrz4pRdV+iT8w=; b=sd9LZ4/fipghZ8ewPb++e2yLBUfjO6PTqUwDSJQJ59EfGYPu1jQXuvVlMCwWR3cgIX v0dnM6YUy1eBiC/y2HKxqKRbMQEzWNatV7SbEQUn5F7hbKH/BwjOND+o3ur0+g/v1qY2 JVaDyr75I7gF2a6FUsPOX/Aev2GE5kzyi6m1GwAYo7x1wDrDbnZgAXI91FQXm6QjNUIR 4bCgaQ46MVtB1xv7iAKkQpHe3Fl1c5XJ2ZTymT5E8sjIh1qKrxm9wQegSs17YI7HWAA4 xWNOOELXvt0BwxIFJcPStsjjRcsWepEo5wt4gGjGxTipTnB2Zn6ckZu09as7rGGGOU/1 sXsQ== X-Gm-Message-State: APjAAAUhSliqBYKZpTCJvWbzP+QqqOr0K3VT1D6Uh1RCVekv7nT0s1jp elwN68s6iEd51JANRZIHo6LQXD5vQLZFTExR0l/Q1Q== X-Google-Smtp-Source: APXvYqyKbO0pWQIzuyHkDkvlBVAiTs5WLd2Ba3MrGQpOOIWqsEP/VD7JvDEsd5m+d/Fn6ot8qp5ZBrUymqOYbw2J9ZM= X-Received: by 2002:a1c:b1c3:: with SMTP id a186mr7073866wmf.10.1573200029305; Fri, 08 Nov 2019 00:00:29 -0800 (PST) MIME-Version: 1.0 References: <20191107090618.15813-1-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A14E539892@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E539892@SHSMSX104.ccr.corp.intel.com> From: "Ard Biesheuvel" Date: Fri, 8 Nov 2019 09:00:18 +0100 Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] BaseTools/GenFw AARCH64: disregard ADRP instructions that are patched already To: "Gao, Liming" Cc: "devel@edk2.groups.io" , "eugene@hp.com" Content-Type: text/plain; charset="UTF-8" On Fri, 8 Nov 2019 at 01:39, Gao, Liming wrote: > > Acked-by: Liming Gao > Thanks all Pushed as 9e9f0be353d4..f55c76b301f1 > >-----Original Message----- > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ard > >Biesheuvel > >Sent: Thursday, November 07, 2019 5:06 PM > >To: devel@edk2.groups.io > >Cc: eugene@hp.com; Ard Biesheuvel > >Subject: [edk2-devel] [PATCH 1/1] BaseTools/GenFw AARCH64: disregard > >ADRP instructions that are patched already > > > >In order to permit the use of compilers that only implement the small > >code model [which involves the use of ADRP instructions that require > >4 KB segment alignment] for generating PE/COFF binaries with a small > >footprint, we patch ADRP instructions into ADR instructions while doing > >the ELF to PE/COFF conversion. > > > >As it turns out, the linker may be doing the same, but for different > >reasons: there is a silicon erratum #843419 for ARM Cortex-A53 which > >affects ADRP instructions appearing at a certain offset in memory, and > >one of the mitigations for this erratum is to patch them into ADR > >instructions at link time if the symbol reference is within -/+ 1 MB. > >However, the LD linker fails to update the static relocation tables, and > >so we end up with an ADR instruction in the fully linked binary, but > >with a relocation entry in the RELA section identifying it as an ADRP > >instruction. > > > >Since the linker has already updated the symbol reference, there is no > >handling needed in GenFw for such instructions, and we can simply treat > >it as an ordinary ADR. However, since it is guaranteed to be accompanied > >by an add or load instruction with a LO12 relocation referencing the same > >symbol, the section offset check we apply to ADR instructions is going to > >take place anyway, so we can just disregard the ADR instruction entirely. > > > >Reported-by: Eugene Cohen > >Suggested-by: Eugene Cohen > >Signed-off-by: Ard Biesheuvel > >--- > > BaseTools/Source/C/GenFw/Elf64Convert.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > >diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c > >b/BaseTools/Source/C/GenFw/Elf64Convert.c > >index d574300ac4fe..d623dce1f9da 100644 > >--- a/BaseTools/Source/C/GenFw/Elf64Convert.c > >+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c > >@@ -1044,6 +1044,19 @@ WriteSections64 ( > > /* fall through */ > > > > case R_AARCH64_ADR_PREL_PG_HI21: > >+ // > >+ // In order to handle Cortex-A53 erratum #843419, the LD linker may > >+ // convert ADRP instructions into ADR instructions, but without > >+ // updating the static relocation type, and so we may end up here > >+ // while the instruction in question is actually ADR. So let's > >+ // just disregard it: the section offset check we apply below to > >+ // ADR instructions will trigger for its R_AARCH64_xxx_ABS_LO12_NC > >+ // companion instruction as well, so it is safe to omit it here. > >+ // > >+ if ((*(UINT32 *)Targ & BIT31) == 0) { > >+ break; > >+ } > >+ > > // > > // AArch64 PG_H21 relocations are typically paired with ABS_LO12 > > // relocations, where a PC-relative reference with +/- 4 GB range is > >-- > >2.17.1 > > > > > > >