paulhuggett
commented
3 years ago Fixed by commit 9ad248a5aef63cb0db73ec43bdc5d4026505997d.
Below is an example of a PHDR table as emitted by rld at this revision. The binary is mapped to start at 0x400000. The PHDR segment overlaps the rodata segment whose contents are no longer over-aligned to the next page boundary.
Elf file type is EXEC (Executable file)
Entry point 0x40101e
There are 5 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000158 0x0000000000000158 R 0x1
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000e20 0x0000000000000e20 R 0x1000
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x0000000000003670 0x0000000000003670 R E 0x1000
LOAD 0x0000000000005000 0x0000000000405000 0x0000000000405000
0x00000000000000f8 0x0000000000000778 RW 0x1000
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
Section to Segment mapping:
Segment Sections...
00
01 .rodata.str1.1 .rodata.cst4 .rodata.cst8 .rodata.cst16 .rodata
02 .text
03 .data .bss
04 (Ignore the multiple .rodata.* sections listed in the segment mapping. I’m aware of this behaviour.)
According to the AMD64 System V ABI (section 3.4.1 ”Initial Stack and Register State”), an ”auxiliary vector” describes some aspects of the process on startup; details are in 3.4.2 ”Auxiliary Vector”. On of the fields that this makes available is AT_PHDR which “tells the interpreter where to find the program header table in the memory image”.
At the time of writing the PHDRs generated by rld do not map this data to the process address space.