On Thu, Sep 27, 2018 at 8:18 AM, Carlos O'Donell wrote: > On 9/27/18 9:20 AM, H.J. Lu wrote: >> On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell wrote: >>> On 9/27/18 8:57 AM, Florian Weimer wrote: >>>> * H. J. Lu: >>>> >>>>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer wrote: >>>>>> * H. J. Lu: >>>>>> >>>>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy wrote: >>>>>>>> an alloc .phdr section covering the program headers solves >>>>>>>> this problem. if sections are not required for segments >>>>>>>> then simply the linker should ensure that there is always >>>>>>>> a load segment covering the program headers, possibly >>>>>>>> without containing any sections, however elf says >>>>>>>> "An object file segment contains one or more sections". >>>>>>>> >>>>>>>> i don't understand why a zero-size section is enough, what >>>>>>>> if phdr > pagesize? will that get covered by the load >>>>>>>> segment that is created for the zero-size section? >>>>>>> >>>>>>> Linker must keep this zero-size section in output and >>>>>>> create a PT_LOAD segment to cover it even if it is >>>>>>> the only SHF_ALLOC section in the PT_LOAD segment. >>>>>> >>>>>> Based on Szabolcs' comment, I don't think the section can be zero-sized. >>>>>> >>>>> >>>>> Why can't we put a zero-size section in a PT_LOAD segment? >>>>> Of course, we need to change linker to do it. >>>> >>>> I'm now under the impression that the bits that are PT_LOAD'ed all need >>>> to be covered by (allocated) sections. A zero-sized section doesn't >>>> cover anything, so it doesn't address this requirement of the ELF >> >> It depends on how we define it. I did experiment SHT_GNU_PHDRS >> to cover the whole program header. But other tools don't expect a >> section covering the program header. > > Which other tools? Specific examples please. Please see the enclosed binary where SHT_GNU_PHDRS section covers the whole program header: [hjl@gnu-cfl-1 ld]$ ../binutils/readelf -lSW foo There are 14 section headers, starting at offset 0x2f00: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .gnu.phdrs GNU_PHDRS 0000000000400040 000040 0000e0 38 A 0 0 8 [ 2] .text PROGBITS 0000000000401000 001000 00014b 00 AX 0 0 16 [ 3] .rodata PROGBITS 0000000000402000 002000 000006 00 A 0 0 1 [ 4] .comment PROGBITS 0000000000000000 002006 00002c 01 MS 0 0 1 [ 5] .debug_aranges PROGBITS 0000000000000000 002040 000060 00 0 0 16 [ 6] .debug_info PROGBITS 0000000000000000 0020a0 000482 00 0 0 1 [ 7] .debug_abbrev PROGBITS 0000000000000000 002522 00016d 00 0 0 1 [ 8] .debug_line PROGBITS 0000000000000000 00268f 000248 00 0 0 1 [ 9] .debug_frame PROGBITS 0000000000000000 0028d8 000040 00 0 0 8 [10] .debug_str PROGBITS 0000000000000000 002918 000374 01 MS 0 0 1 [11] .symtab SYMTAB 0000000000000000 002c90 0001b0 18 12 12 8 [12] .strtab STRTAB 0000000000000000 002e40 000030 00 0 0 1 [13] .shstrtab STRTAB 0000000000000000 002e70 00008a 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) Elf file type is EXEC (Executable file) Entry point 0x401000 There are 4 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x000120 0x000120 R 0x1000 LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x00014b 0x00014b R E 0x1000 LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x000006 0x000006 R 0x1000 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10 Section to Segment mapping: Segment Sections... 00 .gnu.phdrs 01 .text 02 .rodata 03 [hjl@gnu-cfl-1 ld]$ ./foo PASS [hjl@gnu-cfl-1 ld]$ ../binutils/objcopy ./foo bar ../binutils/objcopy: bar: section .gnu.phdrs lma 0x400040 adjusted to 0x401040 [hjl@gnu-cfl-1 ld]$ I can fix objcopy. Other tools may also need adjustment. > The main problem we have to solve is: > > * Segfault when trying to access program headers which are expected to be > mapped in by the leading pages of the PT_LOAD segment. > > We can't solve *all* the problems. > > The correct solution to the above is to improve the semantics that the > toolchain relies upon to map the phdrs. > > Some questions which we might get asked is: > > * How does a running program know it's *safe* to look at it's own phdrs? > > * How many downstream tools are impacted? Do they really need to understand > SHT_GNU_PHDRS? > >>>> specification. >>> >>> I agree. What we did in the past by relying on phdrs to be accidentally >>> in the first PT_LOAD segment always irked me as bad design. >>> >>> If we need access to program header we need clear semantics for doing so, >>> not hackish kludges to force the linker to get it onto a page that also >>> happened to be mapped. This is just poor engineering on our part. >>> >> >> My current dummy program property note section sounds much better >> now :-). > > My apologies HJ, I did not intend this to sound like an attack on your > original design, just that a new design like SHT_GNU_PHDRS could be > created with reliable semantics. None taken. -- H.J.