https://sourceware.org/bugzilla/show_bug.cgi?id=22782
Bug ID: 22782
Summary: ld.bfd large static binaries
Product: binutils
Version: 2.30
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: felix-glibc at fefe dot de
Target Milestone: ---
Created attachment 10782
--> https://sourceware.org/bugzilla/attachment.cgi?id=10782&action=edit
test case (object files and shell script that calls ld)
I wrote a small libc for Linux (www.fefe.de/dietlibc/) and a collection of
small utils to go with it (www.fefe.de/embutils/). With ld.bfd from binutils
2.30 the binary for /bin/true is >4k large. With ld.bfd from earlier binutils
and ld.gold from 2.30 the binary is much smaller.
size true says: text 783 data 24 bss 92.
The thing is: there is no data. true is literally "return true", and my libc
puts errno into TLS not .data and environ into .bss.
If I link with -Wl,-Map,mapfile I can see this:
.got 0x0000000000601000 0x0
*(.got)
.got 0x0000000000601000 0x0 /opt/diet/lib-x86_64/start.o
*(.igot)
0x0000000000601fe8 . = DATA_SEGMENT_RELRO_END
(., (SIZEOF (.got.plt) >= 0x18)?0x18:0x0)
.got.plt 0x0000000000601000 0x18
*(.got.plt)
.got.plt 0x0000000000601000 0x18 /opt/diet/lib-x86_64/start.o
0x0000000000601000 _GLOBAL_OFFSET_TABLE_
Wait, what? a PLT for a static binary? How did this happen?
It appears to me like this and the 4k page alignment are what is responsible
for the larger binaries.
I'll attach a tarball with the object files and a shell script to link them to
this bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
