https://sourceware.org/bugzilla/show_bug.cgi?id=23567
Bug ID: 23567
Summary: much larger static binaries compared to a few months
ago
Product: binutils
Version: 2.32 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: felix-glibc at fefe dot de
Target Milestone: ---
One of my projects is a small libc, for the express purpose of making small
static binaries. It comes with a small wrapper around gcc. Here is the code as
compiled in May (for x86_64-linux both):
-rwxr-xr-x 1 root root 9512 May 2 20:09 /opt/diet/bin/diet
text data bss dec hex filename
6327 672 92 7091 1bb3 /opt/diet/bin/diet
And here is the code as compiled with the current gcc 8.2 and binutils HEAD as
of today:
-rwxr-xr-x 1 leitner users 17784 Aug 23 14:41 bin-x86_64/diet-i
text data bss dec hex filename
6359 672 92 7123 1bd3 bin-x86_64/diet-i
As you can see, the segments are basically the same size, yet the binary is
almost twice as big.
What happened? Is there a command line option to reverse this?
$ readelf -l /opt/diet/bin/diet
Elf file type is EXEC (Executable file)
Entry point 0x400cd7
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000001a10 0x0000000000001a10 R E 0x200000
LOAD 0x0000000000002000 0x0000000000602000 0x0000000000602000
0x00000000000002a0 0x00000000000002f8 RW 0x200000
TLS 0x0000000000002000 0x0000000000602000 0x0000000000602000
0x0000000000000000 0x0000000000000004 R 0x4
GNU_EH_FRAME 0x000000000000175c 0x000000000040175c 0x000000000040175c
0x000000000000008c 0x000000000000008c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame_hdr .eh_frame
01 .data .bss
02 .tbss
03 .eh_frame_hdr
04
$ readelf -l bin-x86_64/diet-i
Elf file type is EXEC (Executable file)
Entry point 0x401b7f
There are 8 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000220 0x0000000000000220 R 0x1000
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x0000000000001286 0x0000000000001286 R E 0x1000
LOAD 0x0000000000003000 0x0000000000403000 0x0000000000403000
0x0000000000000680 0x0000000000000680 R 0x1000
LOAD 0x0000000000004000 0x0000000000405000 0x0000000000405000
0x00000000000002a0 0x00000000000002f8 RW 0x1000
NOTE 0x0000000000000200 0x0000000000400200 0x0000000000400200
0x0000000000000020 0x0000000000000020 R 0x8
TLS 0x0000000000004000 0x0000000000405000 0x0000000000405000
0x0000000000000000 0x0000000000000004 R 0x4
GNU_EH_FRAME 0x00000000000033c8 0x00000000004033c8 0x00000000004033c8
0x000000000000008c 0x000000000000008c R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .note.gnu.property
01 .text
02 .rodata .eh_frame_hdr .eh_frame
03 .data .bss
04 .note.gnu.property
05 .tbss
06 .eh_frame_hdr
07
Please understand that I spent years trying to save a byte of code here and a
byte there, to get binaries to fit into less sectors/pages. This basically
reverses all my work and makes me quite unhappy.
--
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
