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

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

[kernel test robot]

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

tree:   https://github.com/linuxppc/linux next-test
head:   f46b75a9ae95df302fcb070678773574f6812216
commit: 6dcaaad9830c73908a23200ccc5da12583e04f1a [70/80] powerpc/vdso: Switch VDSO to generic C implementation.
config: powerpc64-randconfig-r005-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        git checkout 6dcaaad9830c73908a23200ccc5da12583e04f1a
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> /usr/bin/powerpc64-linux-gnu-ld: warning: discarding dynamic section .rela.opd

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 26774 bytes --]

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

[Nick Desaulniers]

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

On Wed, Aug 26, 2020 at 11:05 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 27/08/2020 à 03:39, kernel test robot a écrit :
> > tree:   https://github.com/linuxppc/linux next-test
> > head:   f46b75a9ae95df302fcb070678773574f6812216
> > commit: 6dcaaad9830c73908a23200ccc5da12583e04f1a [70/80] powerpc/vdso: Switch VDSO to generic C implementation.
> > config: powerpc64-randconfig-r005-20200826 (attached as .config)
> > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 7cfcecece0e0430937cf529ce74d3a071a4dedc6)
> > reproduce (this is a W=1 build):
> >          wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >          chmod +x ~/bin/make.cross
> >          # install powerpc64 cross compiling tool for clang build
> >          # apt-get install binutils-powerpc64-linux-gnu
> >          git checkout 6dcaaad9830c73908a23200ccc5da12583e04f1a
> >          # save the attached .config to linux build tree
> >          COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > 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.
>
> What is going on here with clang ?

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.

Christophe, it might be interesting to find which object file contains
that section pre-linking, then what symbols are in that section.
-- 
Thanks,
~Nick Desaulniers

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

[Ulrich Weigand]

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

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.
> >
> > What is going on here with clang ?
>
> 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
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.

Alan Modra is really the expert on PowerPC linker issues, so I've
added him on CC in case he has further comments.

Bye,
Ulrich

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 1887 bytes --]

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

[Nick Desaulniers]

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

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

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

[Kees Cook]

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

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

[Fangrui Song]

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

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

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?

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

[Nick Desaulniers]

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

On Mon, Aug 31, 2020 at 8:34 PM Fangrui Song <maskray@google.com> wrote:
>
> 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@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
>
> 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

Then this sounds like just another case where big endian support in
LLD is generally broken and should be disabled or unselectable in
Kconfig.

> >>
> >> 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?
-- 
Thanks,
~Nick Desaulniers