I am seeing a strange thing. The (BFD) linker spuriously generates .plt
and .rela.plt sections (both empty) for a link that has no need for them.
It's reproduced with a trivial example, and seen on today's binutils trunk.
Gold does not produce the empty sections.
Empty sections are normally harmless, but in combination with a custom
linker script (and possibly other more arcane bugs in orphan placement
handling empty sections), it produces undesireable results.
Is this a known issue?
Thanks,
Roland
$ cat r.s
.globl foo
foo: ret
.globl _start
_start: call foo
$ as -o r.o r.s
$ objdump -dr r.o
r.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <foo>:
0: c3 retq
0000000000000001 <_start>:
1: e8 00 00 00 00 callq 6 <_start+0x5>
2: R_X86_64_PC32 foo-0x4
$ ld-new -o r r.o
$ readelf -S r
There are 8 section headers, starting at offset 0xf0:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .rela.plt RELA 00000000004000b0 000000b0
0000000000000000 0000000000000018 A 0 2 8
[ 2] .plt PROGBITS 00000000004000b0 000000b0
0000000000000000 0000000000000000 AX 0 0 4
[ 3] .text PROGBITS 00000000004000b0 000000b0
0000000000000006 0000000000000000 AX 0 0 4
[ 4] .got.plt PROGBITS 00000000006000b8 000000b8
0000000000000000 0000000000000000 WA 0 0 8
[ 5] .shstrtab STRTAB 0000000000000000 000000b8
0000000000000034 0000000000000000 0 0 1
[ 6] .symtab SYMTAB 0000000000000000 000002f0
00000000000000f0 0000000000000018 7 5 8
[ 7] .strtab STRTAB 0000000000000000 000003e0
0000000000000024 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
$
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
