On Thu, Aug 27, 2020 at 5:57 PM Alan Modra <amodra(a)gmail.com> wrote:
On Thu, Aug 27, 2020 at 06:02:14PM +0200, Ulrich Weigand wrote:
> Nick Desaulniers <ndesaulniers(a)google.com> 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).
The log didn't provide enough info if linking the vdso was the
problem. computeTargetABI() in
llvm/lib/Target/PowerPC/PPCTargetMachine.cpp seems to imply that ppc64
(big endian) always uses elfv1, unless you specify a machine that
starts with "elfv2" in the ABI.
Christophe, did you test your series for big endian and little endian?
Maybe just an issue for big endian?
> section, and they usually do require relocations since the
function
> descriptor contains the address of the function text (however those
> relocations should be resolved during final link). I don't think
> there should be much difference between GCC and LLVM in how those
> are handled.
.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.
--
Thanks,
~Nick Desaulniers