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=U+xf5zw8; spf=pass (domain: linaro.org, ip: 209.85.221.67, mailfrom: ard.biesheuvel@linaro.org) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by groups.io with SMTP; Wed, 04 Sep 2019 07:22:27 -0700 Received: by mail-wr1-f67.google.com with SMTP id c3so21487180wrd.7 for ; Wed, 04 Sep 2019 07:22:27 -0700 (PDT) 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=to2lAY4q2vZJtg8NwZaB1WdWzA3pG7fLYA44j07E0Ck=; b=U+xf5zw8Wi341Omgut2sjGJ3SwxwtQwueVpyjptSyBxWkdOBH7Z89tCIVmqDs61EP3 pMxwkStg2T3zfEgPQK+BYVeuVZr+J38TCY/LiszukzsPCX684BoR8A5lHnAIDPx9tQuR k2USDLrAzkG7LvvF8pODKVlRWdESpEbYJeo9JM3bTb9rYSIum3g6LWp/kB3asAWMPXLO YTZuSXTvMfJRvcp6bvtpGQQsGDGNNBLcrK3Wt+Dn5fo4LUIfOS7It7B/ZI8eYrzD+rk2 ozBzTE1bx213vhv6ybI1XnFqGtTzkFBfIJKOQewahJ02u8P1IoVMBS3/95zAyxDG8gsx 6RYg== 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=to2lAY4q2vZJtg8NwZaB1WdWzA3pG7fLYA44j07E0Ck=; b=WD5Pn1WewyxnuysaokVhe0ZXha68sxLqfILrHxaNSoXsvA/FMUTnNVvHTUFgbKnn1w En1DDRvppJgz7YNj8et0FFjKCDCJjQs8F/GgG0vcLiFGoXbXXXQBYIgRl8zMGUAsQrf1 tqHxA4lDPHDCP/fZQYqUN+rVGdV0lhf9RJHmaEonufVnMAK32Kjl8KoBRvEf7y5qGnKs Ni+M7gTBLJeDRjK80e8o+eLjx0IQi/2q4PRMRzZ3ey3XEjoWqc+jjqw9bGCsXicGldjh R9R9qb8gvoz3tLywXZA1yyAs1rTbz3+5mhEH1Z+WxOWlVUShEfUrYx4f87xWdItm5Xct cUKg== X-Gm-Message-State: APjAAAV4xbJpdDp8olV5gP36+gfSsWjAMIFPBW3ifTYkdU3wRnm5W7fG W5iv3QfO9lPNvOHcLm6AuZQLQLzBXYrj3wAN915cug== X-Google-Smtp-Source: APXvYqxnj0ShCBtGUqzUmJhE1ZMnm9/lYYadfyGMCYuEOU0odtam0VJVUgzTmtC+grzW0X5vBroSWRPDPH7wXmvg7bw= X-Received: by 2002:adf:9e09:: with SMTP id u9mr48672365wre.169.1567606945824; Wed, 04 Sep 2019 07:22:25 -0700 (PDT) MIME-Version: 1.0 References: <20190904041733.12741-1-ard.biesheuvel@linaro.org> <20190904114933.GG29255@bivouac.eciton.net> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 4 Sep 2019 07:22:13 -0700 Message-ID: Subject: Re: [PATCH] BaseTools/GenFw AARCH64: fix up GOT based relative relocations To: Leif Lindholm Cc: edk2-devel-groups-io , "Gao, Liming" Content-Type: text/plain; charset="UTF-8" On Wed, 4 Sep 2019 at 05:01, Ard Biesheuvel wrote: > > On Wed, 4 Sep 2019 at 04:49, Leif Lindholm wrote: > > > > 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? > > > > I managed to reproduce it on Ubuntu Bionic with clang 6. It may also > be related to the version of ld.gold or the LLVM gold plugin. > > You should be able to test this patch for correctness by stripping the > no-pie/no-pic options from the GCC5 command line, and checking any > produced .dll with readelf -r to see whether any GOT based relocations > were emitted, and whether the resulting binary still runs. I will do > the same locally. > This worked for me, so I am fairly confident that this change is correct. Once we have this change in, I'll double check whether the produced CLANG38 ArmVirtQemuKernel images work as expected.