* 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 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 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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
* 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 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 ` 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 ` 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 ` 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
* 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 ` 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
[parent not found: <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>]
* 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 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 ` 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
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).