[Bug ld/30907] New: ELF segment seperated into 4 LOAD in aarch64, making binary bigger 128KiB than before

[ocs-bot at opencloudos dot tech]

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.