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

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).

> .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.

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?