Re: RFC: Add SHT_GNU_PHDRS

["H.J. Lu" <hjl.tools@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5881 bytes --]

On Thu, Sep 27, 2018 at 8:18 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 9/27/18 9:20 AM, H.J. Lu wrote:
>> On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell <carlos@redhat.com> 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 <fweimer@redhat.com> wrote:
>>>>>> * H. J. Lu:
>>>>>>
>>>>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <nsz@port70.net> 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.

[-- Attachment #2: foo --]
[-- Type: application/octet-stream, Size: 12928 bytes --]