[kbuild-all] Re: [linuxppc:next-test 70/80] /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic section .rela.opd

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 <amodra(a)gmail.com&gt; wrote: >> > >> > On Thu, Aug 27, 2020 at 06:02:14PM +0200, Ulrich Weigand wrote: >> > > Nick Desaulniers <ndesaulniers(a)google.com&gt; 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=warn. 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 only >> > > > hit I get in the codebase of `opd` (at least for tests, still looking >> > > > 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 different 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?