* linux-next: build warnings from Linus' tree
@ 2018-06-11 22:14 Stephen Rothwell
2018-11-14 4:54 ` Joel Stanley
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Rothwell @ 2018-06-11 22:14 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, PowerPC
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Hi all,
Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
produced these warning:
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
This may just be because I have started building using the native Debian
gcc for the powerpc builds ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: build warnings from Linus' tree
2018-06-11 22:14 linux-next: build warnings from Linus' tree Stephen Rothwell
@ 2018-11-14 4:54 ` Joel Stanley
2018-11-14 10:20 ` Michael Ellerman
0 siblings, 1 reply; 5+ messages in thread
From: Joel Stanley @ 2018-11-14 4:54 UTC (permalink / raw)
To: Stephen Rothwell, Alan Modra
Cc: Linux-Next Mailing List, linuxppc-dev, Linux Kernel Mailing List
Hello Alan,
On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced these warning:
>
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>
> This may just be because I have started building using the native Debian
> gcc for the powerpc builds ...
Do you know why we started creating these?
If it's intentional, should we be putting including them in the same
way as .hash sections?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
.hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
Cheers,
Joel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: build warnings from Linus' tree
2018-11-14 4:54 ` Joel Stanley
@ 2018-11-14 10:20 ` Michael Ellerman
2018-11-18 11:22 ` Alan Modra
0 siblings, 1 reply; 5+ messages in thread
From: Michael Ellerman @ 2018-11-14 10:20 UTC (permalink / raw)
To: Joel Stanley, Stephen Rothwell, Alan Modra
Cc: Linux-Next Mailing List, linuxppc-dev, Linux Kernel Mailing List
Joel Stanley <joel@jms.id.au> writes:
> Hello Alan,
>
> On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
>> produced these warning:
>>
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
>>
>> This may just be because I have started building using the native Debian
>> gcc for the powerpc builds ...
>
> Do you know why we started creating these?
It's controlled by the ld option --hash-style, which AFAICS still
defaults to sysv (generating .hash).
But it seems gcc can be configured to have a different default, and at
least my native ppc64le toolchains are passing gnu, eg:
/usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
/usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccw1U2fF.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
-V -shared -m elf64lppc
--hash-style=gnu
^^^^^^^^^^^^^^^^
So that's presumably why we're seeing it, some GCCs are configured to
use it.
> If it's intentional, should we be putting including them in the same
> way as .hash sections?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
>
> .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
That would presumably work.
My question though is do we even need it?
From what I can see for it to be useful you need the section as well as
an entry in the dynamic section pointing at it, and we don't have a
dynamic section at all:
$ readelf -S vmlinux | grep gnu.hash
[ 4] .gnu.hash GNU_HASH c000000000dbbdb0 00dcbdb0
$ readelf -d vmlinux
There is no dynamic section in this file.
Compare to the vdso:
$ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
Dynamic section at offset 0x868 contains 12 entries:
Tag Type Name/Value
0x000000000000000e (SONAME) Library soname: [linux-vdso64.so.1]
0x0000000000000004 (HASH) 0x120
0x000000006ffffef5 (GNU_HASH) 0x170
0x0000000000000005 (STRTAB) 0x320
0x0000000000000006 (SYMTAB) 0x1d0
0x000000000000000a (STRSZ) 269 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000070000003 (PPC64_OPT) 0x0
0x000000006ffffffc (VERDEF) 0x450
0x000000006ffffffd (VERDEFNUM) 2
0x000000006ffffff0 (VERSYM) 0x42e
0x0000000000000000 (NULL) 0x0
So can't we just discard .gnu.hash? And in fact do we need .hash either?
Actually arm64 discards the latter, and parisc discards both.
Would still be good to hear from Alan or someone else who knows anything
about toolchain stuff, ie. not me :)
cheers
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: build warnings from Linus' tree
2018-11-14 10:20 ` Michael Ellerman
@ 2018-11-18 11:22 ` Alan Modra
2018-12-03 23:24 ` Joel Stanley
0 siblings, 1 reply; 5+ messages in thread
From: Alan Modra @ 2018-11-18 11:22 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux-Next Mailing List, Joel Stanley, linuxppc-dev
On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> Joel Stanley <joel@jms.id.au> writes:
> > Hello Alan,
> >
> > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> >> produced these warning:
> >>
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> >>
> >> This may just be because I have started building using the native Debian
> >> gcc for the powerpc builds ...
> >
> > Do you know why we started creating these?
>
> It's controlled by the ld option --hash-style, which AFAICS still
> defaults to sysv (generating .hash).
>
> But it seems gcc can be configured to have a different default, and at
> least my native ppc64le toolchains are passing gnu, eg:
>
> /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
> /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
> -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
> -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
> -V -shared -m elf64lppc
> --hash-style=gnu
> ^^^^^^^^^^^^^^^^
>
> So that's presumably why we're seeing it, some GCCs are configured to
> use it.
>
> > If it's intentional, should we be putting including them in the same
> > way as .hash sections?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> >
> > .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
>
> That would presumably work.
>
> My question though is do we even need it?
>
> >From what I can see for it to be useful you need the section as well as
> an entry in the dynamic section pointing at it, and we don't have a
> dynamic section at all:
>
> $ readelf -S vmlinux | grep gnu.hash
> [ 4] .gnu.hash GNU_HASH c000000000dbbdb0 00dcbdb0
> $ readelf -d vmlinux
>
> There is no dynamic section in this file.
>
> Compare to the vdso:
>
> $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
>
> Dynamic section at offset 0x868 contains 12 entries:
> Tag Type Name/Value
> 0x000000000000000e (SONAME) Library soname: [linux-vdso64.so.1]
> 0x0000000000000004 (HASH) 0x120
> 0x000000006ffffef5 (GNU_HASH) 0x170
> 0x0000000000000005 (STRTAB) 0x320
> 0x0000000000000006 (SYMTAB) 0x1d0
> 0x000000000000000a (STRSZ) 269 (bytes)
> 0x000000000000000b (SYMENT) 24 (bytes)
> 0x0000000070000003 (PPC64_OPT) 0x0
> 0x000000006ffffffc (VERDEF) 0x450
> 0x000000006ffffffd (VERDEFNUM) 2
> 0x000000006ffffff0 (VERSYM) 0x42e
> 0x0000000000000000 (NULL) 0x0
>
>
> So can't we just discard .gnu.hash? And in fact do we need .hash either?
>
> Actually arm64 discards the latter, and parisc discards both.
>
> Would still be good to hear from Alan or someone else who knows anything
> about toolchain stuff, ie. not me :)
.gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
lookup. I imagine you don't need either section in a kernel, so
discarding both sounds reasonable. Likely you could discard .interp
and .dynstr too, and .dynsym when !CONFIG_PPC32.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux-next: build warnings from Linus' tree
2018-11-18 11:22 ` Alan Modra
@ 2018-12-03 23:24 ` Joel Stanley
0 siblings, 0 replies; 5+ messages in thread
From: Joel Stanley @ 2018-12-03 23:24 UTC (permalink / raw)
To: Alan Modra
Cc: Stephen Rothwell, Linux Kernel Mailing List,
Linux-Next Mailing List, linuxppc-dev
On Sun, 18 Nov 2018 at 21:52, Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> > Joel Stanley <joel@jms.id.au> writes:
> > > Hello Alan,
> > >
> > > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> > >> produced these warning:
> > >>
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'.
> > >>
> > >> This may just be because I have started building using the native Debian
> > >> gcc for the powerpc builds ...
> > >
> > > Do you know why we started creating these?
> >
> > It's controlled by the ld option --hash-style, which AFAICS still
> > defaults to sysv (generating .hash).
> >
> > But it seems gcc can be configured to have a different default, and at
> > least my native ppc64le toolchains are passing gnu, eg:
> >
> > /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
> > /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
> > -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
> > -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
> > -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> > -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> > -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
> > -V -shared -m elf64lppc
> > --hash-style=gnu
> > ^^^^^^^^^^^^^^^^
> >
> > So that's presumably why we're seeing it, some GCCs are configured to
> > use it.
> >
> > > If it's intentional, should we be putting including them in the same
> > > way as .hash sections?
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> > >
> > > .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
> >
> > That would presumably work.
> >
> > My question though is do we even need it?
> >
> > >From what I can see for it to be useful you need the section as well as
> > an entry in the dynamic section pointing at it, and we don't have a
> > dynamic section at all:
> >
> > $ readelf -S vmlinux | grep gnu.hash
> > [ 4] .gnu.hash GNU_HASH c000000000dbbdb0 00dcbdb0
> > $ readelf -d vmlinux
> >
> > There is no dynamic section in this file.
> >
> > Compare to the vdso:
> >
> > $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
> >
> > Dynamic section at offset 0x868 contains 12 entries:
> > Tag Type Name/Value
> > 0x000000000000000e (SONAME) Library soname: [linux-vdso64.so.1]
> > 0x0000000000000004 (HASH) 0x120
> > 0x000000006ffffef5 (GNU_HASH) 0x170
> > 0x0000000000000005 (STRTAB) 0x320
> > 0x0000000000000006 (SYMTAB) 0x1d0
> > 0x000000000000000a (STRSZ) 269 (bytes)
> > 0x000000000000000b (SYMENT) 24 (bytes)
> > 0x0000000070000003 (PPC64_OPT) 0x0
> > 0x000000006ffffffc (VERDEF) 0x450
> > 0x000000006ffffffd (VERDEFNUM) 2
> > 0x000000006ffffff0 (VERSYM) 0x42e
> > 0x0000000000000000 (NULL) 0x0
> >
> >
> > So can't we just discard .gnu.hash? And in fact do we need .hash either?
> >
> > Actually arm64 discards the latter, and parisc discards both.
> >
> > Would still be good to hear from Alan or someone else who knows anything
> > about toolchain stuff, ie. not me :)
>
> .gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
> lookup. I imagine you don't need either section in a kernel, so
> discarding both sounds reasonable. Likely you could discard .interp
> and .dynstr too, and .dynsym when !CONFIG_PPC32.
Thanks for the digging Michael, and thanks Alan for clarifying the
details. I'll cook up a patch or two.
Cheers,
Joel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-12-03 23:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-11 22:14 linux-next: build warnings from Linus' tree Stephen Rothwell
2018-11-14 4:54 ` Joel Stanley
2018-11-14 10:20 ` Michael Ellerman
2018-11-18 11:22 ` Alan Modra
2018-12-03 23:24 ` Joel Stanley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).