From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3113179802615589827==" MIME-Version: 1.0 From: Kees Cook 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 19:13:17 -0700 Message-ID: <202008311909.D3519C3@keescook> In-Reply-To: List-Id: --===============3113179802615589827== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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:5= 2: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 > 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 n= ame > > > > shows up on llvm/test/MC/PowerPC/ppc64-relocs-01.s, which is the on= ly > > > > hit I get in the codebase of `opd` (at least for tests, still looki= ng > > > > 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). 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? -- = Kees Cook --===============3113179802615589827==--