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

[Kees Cook <keescook@chromium.org>]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

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@gmail.com> wrote:
> >
> > On Thu, Aug 27, 2020 at 06:02:14PM +0200, Ulrich Weigand wrote:
> > > Nick Desaulniers <ndesaulniers@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

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

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