public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00 RFC: Add SHT_GNU_PHDRS H.J. Lu
@ 2018-01-01  0:00 ` Florian Weimer
  2018-01-01  0:00   ` Jan Beulich
       [not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
  2018-01-01  0:00 ` Carlos O'Donell
  2 siblings, 1 reply; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gnu-gabi, Binutils

* H. J. Lu:

> I am proposing
>
> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>
> This is a special read-only SHF_ALLOC zero-size data section.  It is the
> first output section, which will force a data PT_LOAD segment with program
> header before the code-only PT_LOAD segment,

Is it actually a requirement in the ELF specification that all bits
loaded via segments are covered by sections as well?

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
       [not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
@ 2018-01-01  0:00   ` H.J. Lu
  0 siblings, 0 replies; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Roland McGrath; +Cc: Binutils, gnu-gabi

On Wed, Sep 26, 2018 at 7:53 PM, Roland McGrath <roland@hack.frob.com> wrote:
> Just put the rodata segment first.  That's what lld does and it works great.

Does it work with relro segment?  Also rodata is always required:

[hjl@gnu-cfl-1 ld]$ readelf -SWl  tmpdir/pr23428
There are 13 section headers, starting at offset 0x2008:

Section Headers:
  [Nr] Name              Type            Address          Off    Size
 ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000
000000 00      0   0  0
  [ 1] .note.gnu.property NOTE            0000000000400120 000120
000020 00   A  0   0  8
  [ 2] .text             PROGBITS        0000000000401000 001000
00012d 00  AX  0   0 16
  [ 3] .comment          PROGBITS        0000000000000000 00112d
00002c 01  MS  0   0  1
  [ 4] .debug_aranges    PROGBITS        0000000000000000 001160
000060 00      0   0 16
  [ 5] .debug_info       PROGBITS        0000000000000000 0011c0
000482 00      0   0  1
  [ 6] .debug_abbrev     PROGBITS        0000000000000000 001642
00016d 00      0   0  1
  [ 7] .debug_line       PROGBITS        0000000000000000 0017af
000246 00      0   0  1
  [ 8] .debug_frame      PROGBITS        0000000000000000 0019f8
000040 00      0   0  8
  [ 9] .debug_str        PROGBITS        0000000000000000 001a38
000374 01  MS  0   0  1
  [10] .symtab           SYMTAB          0000000000000000 001db0
000198 18     11  11  8
  [11] .strtab           STRTAB          0000000000000000 001f48
000030 00      0   0  1
  [12] .shstrtab         STRTAB          0000000000000000 001f78
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
0x000140 0x000140 R   0x1000
  LOAD           0x001000 0x0000000000401000 0x0000000000401000
0x00012d 0x00012d R E 0x1000
  NOTE           0x000120 0x0000000000400120 0x0000000000400120
0x000020 0x000020 R   0x8
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.property
   01     .text
   02     .note.gnu.property
   03
[hjl@gnu-cfl-1 ld]$ ./tmpdir/pr23428
[hjl@gnu-cfl-1 ld]$

There is no rodata at all.

> There is also the nacl layout that specifically addresses exactly this issue
> for a platform that requires the code segment to have the lowest address,
> but I don't think any other modern platform actually had such a requirement.
>
> On Wed, Sep 26, 2018, 14:54 H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> When -z separate-code is used to create executable, ld won't place any
>> data in the code-only PT_LOAD segment.  If there are no data sections
>> placed before the code-only PT_LOAD segment, the program headers
>> won't be mapped into any PT_LOAD segment.  When the executable tries
>> to access it (based on the program header address passed in AT_PHDR),ri
>> it will lead to segfault.
>>
>> I am proposing
>>
>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
>>
>> --
>> H.J.
>>
> --
>
>
> Thanks,
> Roland



-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                 ` Carlos O'Donell
@ 2018-01-01  0:00                   ` Cary Coutant
  2018-01-01  0:00                     ` H.J. Lu
  2018-01-01  0:00                   ` H.J. Lu
  1 sibling, 1 reply; 25+ messages in thread
From: Cary Coutant @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, H.J. Lu, nsz, JBeulich, Rich Felker, Binutils, gnu-gabi

> > 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
> > 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.

It seems to me that the kernel loader should make the program headers
available to the dynamic loader through the aux vector, whether
they're part of a PT_LOAD segment or not. That should be part of the
psABI. The gABI clearly requires that the dynamic loader has access to
the program headers (e.g., it needs to find PT_DYNAMIC), but it
doesn't care how the implementation accomplishes that.

-cary

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                   ` H.J. Lu
@ 2018-01-01  0:00                     ` Carlos O'Donell
  2018-01-01  0:00                       ` H.J. Lu
  0 siblings, 1 reply; 25+ messages in thread
From: Carlos O'Donell @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Florian Weimer, Szabolcs Nagy, Jan Beulich, Rich Felker,
	Binutils, gnu-gabi

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.

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.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00   ` Jan Beulich
@ 2018-01-01  0:00     ` Florian Weimer
  2018-01-01  0:00       ` Szabolcs Nagy
  0 siblings, 1 reply; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Jan Beulich; +Cc: H.J. Lu, binutils, gnu-gabi

* Jan Beulich:

>>>> On 27.09.18 at 07:01, <fweimer@redhat.com> wrote:
>> * H. J. Lu:
>> 
>>> I am proposing
>>>
>>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>>>
>>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
>>> first output section, which will force a data PT_LOAD segment with program
>>> header before the code-only PT_LOAD segment,
>> 
>> Is it actually a requirement in the ELF specification that all bits
>> loaded via segments are covered by sections as well?
>
> Hardly, because the presence of a section table isn't required
> in the first place in an executable (iirc).

I think so too, and that is why I don't understand this section hack is
needed.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00 RFC: Add SHT_GNU_PHDRS H.J. Lu
  2018-01-01  0:00 ` Florian Weimer
       [not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
@ 2018-01-01  0:00 ` Carlos O'Donell
  2018-01-01  0:00   ` H.J. Lu
  2 siblings, 1 reply; 25+ messages in thread
From: Carlos O'Donell @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu, gnu-gabi, Binutils

On 9/26/18 5:53 PM, H.J. Lu wrote:
> When -z separate-code is used to create executable, ld won't place any
> data in the code-only PT_LOAD segment.  If there are no data sections
> placed before the code-only PT_LOAD segment, the program headers
> won't be mapped into any PT_LOAD segment.  When the executable tries
> to access it (based on the program header address passed in AT_PHDR),
> it will lead to segfault.
> 
> I am proposing
> 
> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
> 
> This is a special read-only SHF_ALLOC zero-size data section.  It is the
> first output section, which will force a data PT_LOAD segment with program
> header before the code-only PT_LOAD segment,
 
This seems like a huge hack to me. Either ld ensures that the page-aligned
start of the PT_LOAD mapping includes the program headers, or we have to
define SHT_GNU_PHDRS as having exactly that semantic and we need to clearly
explain what a static linker needs to do to accomplish this task. What you
have here needs more documentation.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00       ` Szabolcs Nagy
  2018-01-01  0:00         ` Florian Weimer
@ 2018-01-01  0:00         ` H.J. Lu
  2018-01-01  0:00           ` Florian Weimer
  1 sibling, 1 reply; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Szabolcs Nagy
  Cc: Florian Weimer, Jan Beulich, Rich Felker, Binutils, gnu-gabi

On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> * Florian Weimer <fweimer@redhat.com> [2018-09-27 10:21:40 +0200]:
>> * Jan Beulich:
>> >>>> On 27.09.18 at 07:01, <fweimer@redhat.com> wrote:
>> >> * H. J. Lu:
>> >>
>> >>> I am proposing
>> >>>
>> >>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>> >>>
>> >>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
>> >>> first output section, which will force a data PT_LOAD segment with program
>> >>> header before the code-only PT_LOAD segment,
>> >>
>> >> Is it actually a requirement in the ELF specification that all bits
>> >> loaded via segments are covered by sections as well?
>> >
>> > Hardly, because the presence of a section table isn't required
>> > in the first place in an executable (iirc).
>>
>> I think so too, and that is why I don't understand this section hack is
>> needed.
>
> if there is no read-only alloc section then the program
> headers are currently not part of a load segment.
> https://sourceware.org/bugzilla/show_bug.cgi?id=23428
>
> 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.

-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                   ` Florian Weimer
@ 2018-01-01  0:00                     ` Michael Matz
  0 siblings, 0 replies; 25+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer
  Cc: H.J. Lu, Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

Hi,

On Fri, 28 Sep 2018, Florian Weimer wrote:

> > This section hack isn't necessary at all for what we need.  The link 
> > editor merely needs to ensure that the program headers are part of 
> > some loadable segment, either by placing it not at the start of the 
> > file (though that would mean the ELF header isn't part of the loaded 
> > image, which is desirable to have), or by creating such loadble 
> > segment if necessary.
> >
> > No gABI extensions are needed.
> 
> That would certainly be nice.
> 
> Can we try to update the ELF specification to clarify this?

Maybe.

> That should give us additional feedback whether this reading of the 
> specification is correct.

Well, at least the part about sections being purely optional is undeniably 
true.  The section headers themself were never part of the loaded 
image (nor part of any section for that matter).

Now the but: I would agree that it would be nice if all file contents 
would be covered by some section if section headers are in the file at 
all, simply because the named sections are easier for humans to deal with 
than numbered program headers, so that their use in tools (like e.g. 
readelf -x) is comfortable.  But that's independend and outside of what's 
required by ELF.  If we go down that route then we should go the full way 
and cover the ELF header, the program headers and the section headers with 
sections as well.  I don't see why they would need their own type though, 
PROGBITS is just fine.  And again, all that would be optional and a pure 
QoI issue.


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00               ` Florian Weimer
@ 2018-01-01  0:00                 ` Carlos O'Donell
  2018-01-01  0:00                   ` Cary Coutant
  2018-01-01  0:00                   ` H.J. Lu
  2018-01-01  0:00                 ` Michael Matz
  1 sibling, 2 replies; 25+ messages in thread
From: Carlos O'Donell @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer, H.J. Lu
  Cc: Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

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
> 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.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00     ` Florian Weimer
@ 2018-01-01  0:00       ` Szabolcs Nagy
  2018-01-01  0:00         ` Florian Weimer
  2018-01-01  0:00         ` H.J. Lu
  0 siblings, 2 replies; 25+ messages in thread
From: Szabolcs Nagy @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Jan Beulich, H.J. Lu, Rich Felker, binutils, gnu-gabi

* Florian Weimer <fweimer@redhat.com> [2018-09-27 10:21:40 +0200]:
> * Jan Beulich:
> >>>> On 27.09.18 at 07:01, <fweimer@redhat.com> wrote:
> >> * H. J. Lu:
> >> 
> >>> I am proposing
> >>>
> >>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
> >>>
> >>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
> >>> first output section, which will force a data PT_LOAD segment with program
> >>> header before the code-only PT_LOAD segment,
> >> 
> >> Is it actually a requirement in the ELF specification that all bits
> >> loaded via segments are covered by sections as well?
> >
> > Hardly, because the presence of a section table isn't required
> > in the first place in an executable (iirc).
> 
> I think so too, and that is why I don't understand this section hack is
> needed.

if there is no read-only alloc section then the program
headers are currently not part of a load segment.
https://sourceware.org/bugzilla/show_bug.cgi?id=23428

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?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                 ` Carlos O'Donell
  2018-01-01  0:00                   ` Cary Coutant
@ 2018-01-01  0:00                   ` H.J. Lu
  2018-01-01  0:00                     ` Carlos O'Donell
  1 sibling, 1 reply; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, Szabolcs Nagy, Jan Beulich, Rich Felker,
	Binutils, gnu-gabi

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.

>> 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 :-).

-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                       ` H.J. Lu
@ 2018-01-01  0:00                         ` Carlos O'Donell
  0 siblings, 0 replies; 25+ messages in thread
From: Carlos O'Donell @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Florian Weimer, Szabolcs Nagy, Jan Beulich, Rich Felker,
	Binutils, gnu-gabi

On 9/27/18 12:26 PM, H.J. Lu wrote:
> [hjl@gnu-cfl-1 ld]$ ../binutils/objcopy ./foo  bar
> ../binutils/objcopy: bar: section .gnu.phdrs lma 0x400040 adjusted to 0x401040

What is it doing here? Why is it adjusting the lma? How odd.

> [hjl@gnu-cfl-1 ld]$
> 
> I can fix objcopy.  Other tools may also need adjustment.

Yes, this just looks like bugs.

* Unknown section types should not be adjusted or touched and minimally passed
  through during a copy. We should not adjust them to the next PROGBITS section.

* Backports of the fix to active branches to enable distributions to easily
  pickup the fixes.

... and keep moving forward with a proper fix (and consensus around it).


-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00 ` Carlos O'Donell
@ 2018-01-01  0:00   ` H.J. Lu
  0 siblings, 0 replies; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: gnu-gabi, Binutils

On Wed, Sep 26, 2018 at 8:25 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 9/26/18 5:53 PM, H.J. Lu wrote:
>> When -z separate-code is used to create executable, ld won't place any
>> data in the code-only PT_LOAD segment.  If there are no data sections
>> placed before the code-only PT_LOAD segment, the program headers
>> won't be mapped into any PT_LOAD segment.  When the executable tries
>> to access it (based on the program header address passed in AT_PHDR),
>> it will lead to segfault.
>>
>> I am proposing
>>
>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
>
> This seems like a huge hack to me. Either ld ensures that the page-aligned
> start of the PT_LOAD mapping includes the program headers, or we have to
> define SHT_GNU_PHDRS as having exactly that semantic and we need to clearly
> explain what a static linker needs to do to accomplish this task. What you
> have here needs more documentation.

It is to replace another hack:

[hjl@gnu-cfl-1 ld]$ readelf -SWl  tmpdir/pr23428
There are 13 section headers, starting at offset 0x2008:

Section Headers:
  [Nr] Name              Type            Address          Off    Size
 ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000
000000 00      0   0  0
  [ 1] .note.gnu.property NOTE            0000000000400120 000120
000020 00   A  0   0  8
  [ 2] .text             PROGBITS        0000000000401000 001000
00012d 00  AX  0   0 16
  [ 3] .comment          PROGBITS        0000000000000000 00112d
00002c 01  MS  0   0  1
  [ 4] .debug_aranges    PROGBITS        0000000000000000 001160
000060 00      0   0 16
  [ 5] .debug_info       PROGBITS        0000000000000000 0011c0
000482 00      0   0  1
  [ 6] .debug_abbrev     PROGBITS        0000000000000000 001642
00016d 00      0   0  1
  [ 7] .debug_line       PROGBITS        0000000000000000 0017af
000246 00      0   0  1
  [ 8] .debug_frame      PROGBITS        0000000000000000 0019f8
000040 00      0   0  8
  [ 9] .debug_str        PROGBITS        0000000000000000 001a38
000374 01  MS  0   0  1
  [10] .symtab           SYMTAB          0000000000000000 001db0
000198 18     11  11  8
  [11] .strtab           STRTAB          0000000000000000 001f48
000030 00      0   0  1
  [12] .shstrtab         STRTAB          0000000000000000 001f78
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
0x000140 0x000140 R   0x1000
  LOAD           0x001000 0x0000000000401000 0x0000000000401000
0x00012d 0x00012d R E 0x1000
  NOTE           0x000120 0x0000000000400120 0x0000000000400120
0x000020 0x000020 R   0x8
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.property
   01     .text
   02     .note.gnu.property
   03
[hjl@gnu-cfl-1 ld]$ ./tmpdir/pr23428
[hjl@gnu-cfl-1 ld]$

I added a "dummy" .note.gnu.property section in x86 backend so that
program header
can be in a data PT_LOAD segment.

-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                 ` Michael Matz
@ 2018-01-01  0:00                   ` Florian Weimer
  2018-01-01  0:00                     ` Michael Matz
  0 siblings, 1 reply; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Michael Matz
  Cc: H.J. Lu, Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

* Michael Matz:

> On Thu, 27 Sep 2018, Florian Weimer wrote:
>
>> I'm now under the impression that the bits that are PT_LOAD'ed all need 
>> to be covered by (allocated) sections.
>
> That is wrong.  Szabolcs is reading too much into some careless wording of 
> the ELF text that simply tries to convey the idea that usually segments 
> contents are the result of some sections combined by the link editor.  
> Sections are purely optional in the execution view.
>
> This section hack isn't necessary at all for what we need.  The link 
> editor merely needs to ensure that the program headers are part of some 
> loadable segment, either by placing it not at the start of the file 
> (though that would mean the ELF header isn't part of the loaded image, 
> which is desirable to have), or by creating such loadble segment if 
> necessary.
>
> No gABI extensions are needed.

That would certainly be nice.

Can we try to update the ELF specification to clarify this?  That should
give us additional feedback whether this reading of the specification is
correct.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00           ` Florian Weimer
@ 2018-01-01  0:00             ` H.J. Lu
  2018-01-01  0:00               ` Florian Weimer
  0 siblings, 1 reply; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

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.

-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00         ` Florian Weimer
@ 2018-01-01  0:00           ` Cary Coutant
  0 siblings, 0 replies; 25+ messages in thread
From: Cary Coutant @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer; +Cc: nsz, JBeulich, H.J. Lu, Rich Felker, Binutils, gnu-gabi

> * Szabolcs Nagy:
>
> > without containing any sections, however elf says
> > "An object file segment contains one or more sections".
>
> Interesting.  This indeed suggests that a covering section for the
> program header is needed, and a new section type for it makes sense.

I would argue that "one or more" is careless wording. It goes on to
say "... though this fact is transparent to the program header.
Whether the file segment holds one or many sections also is immaterial
to program loading."

If you need a special section type just to ensure that the BFD linker
will include the program headers in a loadable segment, that's a mere
implementation detail, and doesn't need to be part of the gABI or
psABI.

-cary

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                   ` Cary Coutant
@ 2018-01-01  0:00                     ` H.J. Lu
  2018-01-01  0:00                       ` Rich Felker
  0 siblings, 1 reply; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Cary Coutant
  Cc: Carlos O'Donell, Florian Weimer, Szabolcs Nagy, Jan Beulich,
	Rich Felker, Binutils, gnu-gabi

On Thu, Sep 27, 2018 at 3:34 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>> > 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
>> > 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.
>
> It seems to me that the kernel loader should make the program headers
> available to the dynamic loader through the aux vector, whether
> they're part of a PT_LOAD segment or not. That should be part of the
> psABI. The gABI clearly requires that the dynamic loader has access to
> the program headers (e.g., it needs to find PT_DYNAMIC), but it
> doesn't care how the implementation accomplishes that.
>

Dynamic loader has no problem.  The problem is kernel passes
AT_PHDR to main, which points to the unmmaped address.   We can
ask for kernel change or make kernel happy.

My current .note.gnu.property patch only works for x86.   We can
add

#define GNU_PROPERTY_PHDRS 3

so that it can be used for all targets.


-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00       ` Szabolcs Nagy
@ 2018-01-01  0:00         ` Florian Weimer
  2018-01-01  0:00           ` Cary Coutant
  2018-01-01  0:00         ` H.J. Lu
  1 sibling, 1 reply; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Szabolcs Nagy; +Cc: Jan Beulich, H.J. Lu, Rich Felker, binutils, gnu-gabi

* Szabolcs Nagy:

> without containing any sections, however elf says
> "An object file segment contains one or more sections".

Interesting.  This indeed suggests that a covering section for the
program header is needed, and a new section type for it makes sense.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00 ` Florian Weimer
@ 2018-01-01  0:00   ` Jan Beulich
  2018-01-01  0:00     ` Florian Weimer
  0 siblings, 1 reply; 25+ messages in thread
From: Jan Beulich @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer; +Cc: H.J. Lu, binutils, gnu-gabi

>>> On 27.09.18 at 07:01, <fweimer@redhat.com> wrote:
> * H. J. Lu:
> 
>> I am proposing
>>
>> #define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section.  It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
> 
> Is it actually a requirement in the ELF specification that all bits
> loaded via segments are covered by sections as well?

Hardly, because the presence of a section table isn't required
in the first place in an executable (iirc).

Jan


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                     ` H.J. Lu
@ 2018-01-01  0:00                       ` Rich Felker
  0 siblings, 0 replies; 25+ messages in thread
From: Rich Felker @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Cary Coutant, Carlos O'Donell, Florian Weimer, Szabolcs Nagy,
	Jan Beulich, Binutils, gnu-gabi

On Fri, Sep 28, 2018 at 06:42:52AM -0700, H.J. Lu wrote:
> On Thu, Sep 27, 2018 at 3:34 PM, Cary Coutant <ccoutant@gmail.com> wrote:
> >> > 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
> >> > 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.
> >
> > It seems to me that the kernel loader should make the program headers
> > available to the dynamic loader through the aux vector, whether
> > they're part of a PT_LOAD segment or not. That should be part of the
> > psABI. The gABI clearly requires that the dynamic loader has access to
> > the program headers (e.g., it needs to find PT_DYNAMIC), but it
> > doesn't care how the implementation accomplishes that.
> >
> 
> Dynamic loader has no problem.  The problem is kernel passes
> AT_PHDR to main, which points to the unmmaped address.   We can
> ask for kernel change or make kernel happy.

Kernel change does not help because nobody is obligated to use a new
kernel. Binutils would be producing binaries that don't work on
existing kernels (if the note hack were reverted or if similar changes
were added to other archs without a note hack; right now of course
it's working again).

> My current .note.gnu.property patch only works for x86.   We can
> add
> 
> #define GNU_PROPERTY_PHDRS 3
> 
> so that it can be used for all targets.

What would this do?

Rich

^ permalink raw reply	[flat|nested] 25+ messages in thread

* RFC: Add SHT_GNU_PHDRS
@ 2018-01-01  0:00 H.J. Lu
  2018-01-01  0:00 ` Florian Weimer
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: gnu-gabi, Binutils

When -z separate-code is used to create executable, ld won't place any
data in the code-only PT_LOAD segment.  If there are no data sections
placed before the code-only PT_LOAD segment, the program headers
won't be mapped into any PT_LOAD segment.  When the executable tries
to access it (based on the program header address passed in AT_PHDR),
it will lead to segfault.

I am proposing

#define SHT_GNU_PHDRS  0x6ffffff4  /* Dummy section for program header */

This is a special read-only SHF_ALLOC zero-size data section.  It is the
first output section, which will force a data PT_LOAD segment with program
header before the code-only PT_LOAD segment,

-- 
H.J.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00             ` H.J. Lu
@ 2018-01-01  0:00               ` Florian Weimer
  2018-01-01  0:00                 ` Carlos O'Donell
  2018-01-01  0:00                 ` Michael Matz
  0 siblings, 2 replies; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

* 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
specification.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00                     ` Carlos O'Donell
@ 2018-01-01  0:00                       ` H.J. Lu
  2018-01-01  0:00                         ` Carlos O'Donell
  0 siblings, 1 reply; 25+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, Szabolcs Nagy, Jan Beulich, Rich Felker,
	Binutils, gnu-gabi

[-- 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 --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00         ` H.J. Lu
@ 2018-01-01  0:00           ` Florian Weimer
  2018-01-01  0:00             ` H.J. Lu
  0 siblings, 1 reply; 25+ messages in thread
From: Florian Weimer @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

* 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.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: RFC: Add SHT_GNU_PHDRS
  2018-01-01  0:00               ` Florian Weimer
  2018-01-01  0:00                 ` Carlos O'Donell
@ 2018-01-01  0:00                 ` Michael Matz
  2018-01-01  0:00                   ` Florian Weimer
  1 sibling, 1 reply; 25+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer
  Cc: H.J. Lu, Szabolcs Nagy, Jan Beulich, Rich Felker, Binutils, gnu-gabi

Hi,

On Thu, 27 Sep 2018, Florian Weimer wrote:

> I'm now under the impression that the bits that are PT_LOAD'ed all need 
> to be covered by (allocated) sections.

That is wrong.  Szabolcs is reading too much into some careless wording of 
the ELF text that simply tries to convey the idea that usually segments 
contents are the result of some sections combined by the link editor.  
Sections are purely optional in the execution view.

This section hack isn't necessary at all for what we need.  The link 
editor merely needs to ensure that the program headers are part of some 
loadable segment, either by placing it not at the start of the file 
(though that would mean the ELF header isn't part of the loaded image, 
which is desirable to have), or by creating such loadble segment if 
necessary.

No gABI extensions are needed.


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2018-09-28 14:31 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-01  0:00 RFC: Add SHT_GNU_PHDRS H.J. Lu
2018-01-01  0:00 ` Florian Weimer
2018-01-01  0:00   ` Jan Beulich
2018-01-01  0:00     ` Florian Weimer
2018-01-01  0:00       ` Szabolcs Nagy
2018-01-01  0:00         ` Florian Weimer
2018-01-01  0:00           ` Cary Coutant
2018-01-01  0:00         ` H.J. Lu
2018-01-01  0:00           ` Florian Weimer
2018-01-01  0:00             ` H.J. Lu
2018-01-01  0:00               ` Florian Weimer
2018-01-01  0:00                 ` Carlos O'Donell
2018-01-01  0:00                   ` Cary Coutant
2018-01-01  0:00                     ` H.J. Lu
2018-01-01  0:00                       ` Rich Felker
2018-01-01  0:00                   ` H.J. Lu
2018-01-01  0:00                     ` Carlos O'Donell
2018-01-01  0:00                       ` H.J. Lu
2018-01-01  0:00                         ` Carlos O'Donell
2018-01-01  0:00                 ` Michael Matz
2018-01-01  0:00                   ` Florian Weimer
2018-01-01  0:00                     ` Michael Matz
     [not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
2018-01-01  0:00   ` H.J. Lu
2018-01-01  0:00 ` Carlos O'Donell
2018-01-01  0:00   ` H.J. Lu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).