From: Joel Stanley <joel@jms.id.au> Date: 2018-11-14 03:04:42
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
symbols")[1], 32 bit targets can produce .branch_lt sections in their
output.
Include these symbols in the .data section as the ppc64 kernel does.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
I wasn't sure where this should go or if the ordering matters.
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
From: Alan Modra <hidden> Date: 2018-11-14 04:03:12
On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
symbols")[1], 32 bit targets can produce .branch_lt sections in their
output.
Include these symbols in the .data section as the ppc64 kernel does.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alan Modra <redacted>
Looks fine to me.
---
I wasn't sure where this should go or if the ordering matters.
The usual answer is: "Look at where the section goes in the standard
linker scripts." But that doesn't apply here. The section will be
empty for a kernel build so it doesn't matter where it goes.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-11-15 12:52:17
Alan Modra [off-list ref] writes:
On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
quoted
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
symbols")[1], 32 bit targets can produce .branch_lt sections in their
output.
Include these symbols in the .data section as the ppc64 kernel does.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alan Modra <redacted>
Looks fine to me.
quoted
---
I wasn't sure where this should go or if the ordering matters.
The usual answer is: "Look at where the section goes in the standard
linker scripts." But that doesn't apply here. The section will be
empty for a kernel build so it doesn't matter where it goes.
If it's empty why don't we just discard it?
cheers
From: Alan Modra <hidden> Date: 2018-11-18 08:29:13
On Thu, Nov 15, 2018 at 11:47:52PM +1100, Michael Ellerman wrote:
Alan Modra [off-list ref] writes:
quoted
On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
quoted
I wasn't sure where this should go or if the ordering matters.
The usual answer is: "Look at where the section goes in the standard
linker scripts." But that doesn't apply here. The section will be
empty for a kernel build so it doesn't matter where it goes.
If it's empty why don't we just discard it?
That can be a recipe for finding linker bugs. Not that I'm against
you finding linker bugs. ;-)
--
Alan Modra
Australia Development Lab, IBM
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-12-19 09:53:18
Alan Modra [off-list ref] writes:
On Thu, Nov 15, 2018 at 11:47:52PM +1100, Michael Ellerman wrote:
quoted
Alan Modra [off-list ref] writes:
quoted
On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
quoted
I wasn't sure where this should go or if the ordering matters.
The usual answer is: "Look at where the section goes in the standard
linker scripts." But that doesn't apply here. The section will be
empty for a kernel build so it doesn't matter where it goes.
If it's empty why don't we just discard it?
That can be a recipe for finding linker bugs. Not that I'm against
you finding linker bugs. ;-)
Seems we might have found a linker bug :)
With a binutils 2.29 toolchain discarding .branch_lt causes a segfault
when linking:
http://kisskb.ellerman.id.au/kisskb/buildresult/13618838/log/
/kisskb/src/scripts/link-vmlinux.sh: line 85: 74627 Segmentation fault (core dumped) ${LD} ${KBUILD_LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${objects}
That toolchain is here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/x86_64-gcc-5.5.0-nolibc-powerpc64-linux.tar.xz
It seems to be better with binutils 2.30, it doesn't crash but still
doesn't link:
http://kisskb.ellerman.id.au/kisskb/buildresult/13620269/log/
/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld: linkage table error against `0002bf55.xdp_rxq_info_reg_mem_model'
/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld: stubs don't match calculated size
/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld: can not build stubs: Bad value
make[1]: *** [/kisskb/src/Makefile:1036: vmlinux] Error 1
So I guess I'll take this version of the patch for now.
cheers
From: Michael Ellerman <hidden> Date: 2019-02-08 14:35:58
On Wed, 2018-11-14 at 03:02:18 UTC, Joel Stanley wrote:
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
symbols")[1], 32 bit targets can produce .branch_lt sections in their
output.
Include these symbols in the .data section as the ppc64 kernel does.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alan Modra <redacted>