From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-02-27 05:01:51
Relocatable kernel builds produce a warning about .gnu.hash being an
orphan section:
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'
If we try to discard it the build fails:
ld -EL -m elf64lppc -pie --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o
...
sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
--start-group lib/lib.a --end-group
ld: could not find section .gnu.hash
So add an entry to explicitly retain it, as we do for .hash.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-02-27 05:03:35
The .interp section specifies which "interpreter", ie. dynamic loader,
the kernel requests. But that doesn't make any sense, the kernel is
not a regular binary that is run with an interpreter.
The content seems to be some default value, this file doesn't even
exist on my system:
00000000 2f 75 73 72 2f 6c 69 62 2f 6c 64 2e 73 6f 2e 31 |/usr/lib/ld.so.1|
So the section serves no useful purpose and consumes a small amount of
space.
Also Alan Modra says we "likely could discard" it, so do so.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Alan Modra <hidden> Date: 2020-02-27 06:23:41
On Thu, Feb 27, 2020 at 03:59:32PM +1100, Michael Ellerman wrote:
Relocatable kernel builds produce a warning about .gnu.hash being an
orphan section:
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'
If we try to discard it the build fails:
ld -EL -m elf64lppc -pie --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o
...
sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
--start-group lib/lib.a --end-group
ld: could not find section .gnu.hash
So add an entry to explicitly retain it, as we do for .hash.
Looks fine to me. You can also pass --hash-style=sysv to ld (since
binutils-2.18) to disable generation of .gnu.hash.
From: Alan Modra <hidden> Date: 2020-02-27 06:29:45
On Thu, Feb 27, 2020 at 03:59:33PM +1100, Michael Ellerman wrote:
The .interp section specifies which "interpreter", ie. dynamic loader,
the kernel requests. But that doesn't make any sense, the kernel is
not a regular binary that is run with an interpreter.
The content seems to be some default value, this file doesn't even
exist on my system:
00000000 2f 75 73 72 2f 6c 69 62 2f 6c 64 2e 73 6f 2e 31 |/usr/lib/ld.so.1|
So the section serves no useful purpose and consumes a small amount of
space.
Also Alan Modra says we "likely could discard" it, so do so.
Yes, but you ought to check with the mimimum required binutils. It is
quite possible that an older linker will blow up.
If the minimum required binutils is at least binutils-2.26 then
passing --no-dynamic-linker to ld is a more elegant solution.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-03-27 09:29:07
Alan Modra [off-list ref] writes:
On Thu, Feb 27, 2020 at 03:59:33PM +1100, Michael Ellerman wrote:
quoted
The .interp section specifies which "interpreter", ie. dynamic loader,
the kernel requests. But that doesn't make any sense, the kernel is
not a regular binary that is run with an interpreter.
The content seems to be some default value, this file doesn't even
exist on my system:
00000000 2f 75 73 72 2f 6c 69 62 2f 6c 64 2e 73 6f 2e 31 |/usr/lib/ld.so.1|
So the section serves no useful purpose and consumes a small amount of
space.
Also Alan Modra says we "likely could discard" it, so do so.
Yes, but you ought to check with the mimimum required binutils. It is
quite possible that an older linker will blow up.
OK, I guess I'll have to test.
If the minimum required binutils is at least binutils-2.26 then
passing --no-dynamic-linker to ld is a more elegant solution.
The current minimum is 2.21, though there's talk of increasing it to
2.23.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2020-03-27 09:30:58
Alan Modra [off-list ref] writes:
On Thu, Feb 27, 2020 at 03:59:32PM +1100, Michael Ellerman wrote:
quoted
Relocatable kernel builds produce a warning about .gnu.hash being an
orphan section:
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'
If we try to discard it the build fails:
ld -EL -m elf64lppc -pie --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o
...
sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
--start-group lib/lib.a --end-group
ld: could not find section .gnu.hash
So add an entry to explicitly retain it, as we do for .hash.
Looks fine to me. You can also pass --hash-style=sysv to ld (since
binutils-2.18) to disable generation of .gnu.hash.
Our current minimum is 2.21, so that's probably 5-10 years away :)
cheers
From: Michael Ellerman <hidden> Date: 2020-04-01 13:22:44
On Thu, 2020-02-27 at 04:59:32 UTC, Michael Ellerman wrote:
Relocatable kernel builds produce a warning about .gnu.hash being an
orphan section:
ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'
If we try to discard it the build fails:
ld -EL -m elf64lppc -pie --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o
...
sound/built-in.a net/built-in.a virt/built-in.a --no-whole-archive
--start-group lib/lib.a --end-group
ld: could not find section .gnu.hash
So add an entry to explicitly retain it, as we do for .hash.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>