From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4147021770449428818==" MIME-Version: 1.0 From: Fangrui Song To: kbuild-all@lists.01.org Subject: Re: [linuxppc:next-test 70/80] /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic section .rela.opd Date: Mon, 31 Aug 2020 20:34:21 -0700 Message-ID: <20200901033421.np2qcjwa23vkookk@google.com> In-Reply-To: <202008311909.D3519C3@keescook> List-Id: --===============4147021770449428818== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 2020-08-31, Kees Cook wrote: >On Thu, Aug 27, 2020 at 08:29:56PM -0700, Nick Desaulniers wrote: >> On Thu, Aug 27, 2020 at 5:57 PM Alan Modra wrote: >> > >> > On Thu, Aug 27, 2020 at 06:02:14PM +0200, Ulrich Weigand wrote: >> > > Nick Desaulniers wrote on 27.08.2020 14:= 52:36: >> > > >> > > > > > All warnings (new ones prefixed by >>): >> > > > > > >> > > > > >>> /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic >> > > > section .rela.opd >> > > > > > >> > > > > >> > > > > We have /DISCARD/ *(.rela*) in the VDSO linker scripts. >> >> Indeed, I see that in arch/powerpc/kernel/vdso64/vdso64.lds.S. Kees, >> Fangrui, does `.rela*` not match `.rela.opd`? That doesn't sound > >It does not. For linker scripts, "*" does not match "." (which is why >".." is sometimes used to keep a subsection out of a "whatever.*" match. >X_X In linker scripts, "*" matches "." Is the relocation section from --emit-relocs? --emit-relocs emitted sections are not matched by output section descriptions. >> right. Unless it's not the vdso link that's producing the warning? I >> guess the warning is from GNU BFD, not LLD. Maybe the warning is >> coming from linking a different object file that doesn't use the same >> linker script, or perhaps the `-T` argument is being dropped? >> >> > > > > >> > > > > What is going on here with clang ? >> >> This warning is from the linker flag --orphan-handling=3Dwarn. It's >> been very handy for us to find bugs for other architectures and Kees >> has been working on a large series to use it in arm, arm64, and x86. >> >> So the general question is, should we keep the section or discard it, >> or should it not be produced in the first place? >> >> > > > >> > > > Looks like .rela.opd was maybe synthesized. cc Dr. Weigand, whos = name >> > > > shows up on llvm/test/MC/PowerPC/ppc64-relocs-01.s, which is the o= nly >> > > > hit I get in the codebase of `opd` (at least for tests, still look= ing >> > > > to see if ".opd" gets appended somewhere. >> > > >> > > Well, this is the old ELFv1 ABI for big-endian PowerPC, which uses >> > > function descriptors, which reside in the .opd section. These are >> > > emitted by LLVM in the PPCLinuxAsmPrinter::emitFunctionEntryLabel >> >> Ah, "official procedure descriptors" -> opd. Christophe, do we expect >> the vdso to be ELFv1 ABI? This code in LLVM has two other cases: >> 1. ppc32 >> 2. ELFv2 >> If it should not be ELFv1, then something may be amiss in kbuild when >> building for Clang; maybe Clang has a different command line option >> for v2 and there's a cc-option check that's silently failing. Maybe >> clang has a different implicit default than gcc (which should be fixed >> in clang if so). LLD does not have ppc64 ELF v1 support. It had incomplete support which was= removed https://reviews.llvm.org/D46316 I know very little about ELF v1, but I can tell that R_PPC64_REL24 has diff= erent semantics with ELF v1, which will assuredly be broken by LLD. >If it's not produced by bfd, then nothing should be depending on it >currently, yes? > >> > .opd can only be resolved at link time when creating fixed position >> > executables. .opd does need dynamic relocs in PIEs or shared >> > libraries. >> > >> > Kernel VDSO is rather special though, and I'm not up to speed with >> > whatever hackery the kernel folk use to create it and/or relocate it >> > when the kernel is relocated. Quite possibly the warning should just >> > be ignored. >> >> I'm not sure if the kernel does relocations upon vdso load. > >I won't try to guess about PPC. :) In general, though, the vdso doesn't >get a relocation "pass" in that the code page is shared by all >processes. So I'd expect rela.opd to be empty or unused. Is it empty in >the final image? --===============4147021770449428818==--