https://sourceware.org/bugzilla/show_bug.cgi?id=30907
Bug ID: 30907
Summary: ELF segment seperated into 4 LOAD in aarch64, making
binary bigger 128KiB than before
Product: binutils
Version: 2.39
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ocs-bot at opencloudos dot tech
Target Milestone: ---
When we use binutils 2.39 (or higher, like 2.40) to compile files on aarch64,
we find that the newly compiled binary file size is 128K larger than the binary
file compiled using binutils 2.38.
We found that the binary compiled with 2.38 has only two LOAD segments, but the
file compiled with 2.39 has four LOAD segments, and aarch64 uses 64K alignment
by default(even if we set default aarch64 kernel PAGESIZE to 4K), which makes
the two extra LOAD segments directly occupied 128K, finally makes all the
binaries compiled under version 2.39 or higher are 128K bigger than before.
Below is a example:
**pam compiled under binutils-2.38, two LOAD segments: **
readelf -l usr/lib64/security/pam_access.so
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000003448 0x0000000000003448 R E 0x10000
LOAD 0x000000000000fc60 0x000000000001fc60 0x000000000001fc60
0x00000000000003a8 0x00000000000003b0 RW 0x10000
DYNAMIC 0x000000000000fc70 0x000000000001fc70 0x000000000001fc70
0x0000000000000220 0x0000000000000220 RW 0x8
NOTE 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x0000000000000020 0x0000000000000020 R 0x8
NOTE 0x0000000000000258 0x0000000000000258 0x0000000000000258
0x0000000000000024 0x0000000000000024 R 0x4
LOOS+0x474e553 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x0000000000000020 0x0000000000000020 R 0x8
GNU_EH_FRAME 0x0000000000002f48 0x0000000000002f48 0x0000000000002f48
0x00000000000000a4 0x00000000000000a4 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x000000000000fc60 0x000000000001fc60 0x000000000001fc60
0x00000000000003a0 0x00000000000003a0 R 0x1
Section to Segment mapping:
Segment Sections...
00 .note.gnu.property .note.gnu.build-id .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata
.eh_frame_hdr .eh_frame
01 .init_array .fini_array .dynamic .got .data .bss
02 .dynamic
03 .note.gnu.property
04 .note.gnu.build-id
05 .note.gnu.property
06 .eh_frame_hdr
07
08 .init_array .fini_array .dynamic .got
ls -lh usr/lib64/security/pam_access.so
-rwxr-xr-x 1 root root 68K Apr 28 21:54 /usr/lib64/security/pam_access.so
** pam compiled under binutils 2.39, four LOAD segment with 64k align:**
readelf -l usr/lib64/security/pam_access.so
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 11 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000001168 0x0000000000001168 R 0x10000
LOAD 0x0000000000010000 0x0000000000010000 0x0000000000010000
0x0000000000001dc0 0x0000000000001dc0 R E 0x10000
LOAD 0x0000000000020000 0x0000000000020000 0x0000000000020000
0x0000000000000a8c 0x0000000000000a8c R 0x10000
LOAD 0x000000000002fc30 0x000000000003fc30 0x000000000003fc30
0x00000000000003d8 0x00000000000003e0 RW 0x10000
DYNAMIC 0x000000000002fc40 0x000000000003fc40 0x000000000003fc40
0x0000000000000220 0x0000000000000220 RW 0x8
NOTE 0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
0x0000000000000020 0x0000000000000020 R 0x8
NOTE 0x00000000000002c8 0x00000000000002c8 0x00000000000002c8
0x0000000000000024 0x0000000000000024 R 0x4
LOOS+0x474e553 0x00000000000002a8 0x00000000000002a8 0x00000000000002a8
0x0000000000000020 0x0000000000000020 R 0x8
GNU_EH_FRAME 0x0000000000020510 0x0000000000020510 0x0000000000020510
0x00000000000000ac 0x00000000000000ac R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x000000000002fc30 0x000000000003fc30 0x000000000003fc30
0x00000000000003d0 0x00000000000003d0 R 0x1
Section to Segment mapping:
Segment Sections...
00 .note.gnu.property .note.gnu.build-id .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt
01 .init .plt .text .fini
02 .rodata .eh_frame_hdr .eh_frame
03 .init_array .fini_array .dynamic .got .data .bss
04 .dynamic
05 .note.gnu.property
06 .note.gnu.build-id
07 .note.gnu.property
08 .eh_frame_hdr
09
10 .init_array .fini_array .dynamic .got
ls -lh usr/lib64/security/pam_access.so
-rwxr-xr-x 1 root root 196K Sep 8 23:19 usr/lib64/security/pam_access.so
It Can be reproduced on Fedora 39(using 2.40) and Fedora 37 (using 2.38).
Thanks a lot!
--
You are receiving this mail because:
You are on the CC list for the bug.
