This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: Add a GNU_PROPERTY_X86_ISA_1_USED note if needed


On Fri, Jul 20, 2018 at 06:38:52AM -0700, H.J. Lu wrote:
> On Fri, Jul 20, 2018 at 6:31 AM, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Jul 20, 2018 at 05:24:08AM -0700, H.J. Lu wrote:
> >> On Fri, Jul 20, 2018 at 2:30 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >> > On 19/07/18 22:33, H.J. Lu wrote:
> >> >>
> >> >> Here is the updated patch.  Any comments?
> >> >>
> >> >>
> >> >> H.J.
> >> >> --
> >> >> When -z separate-code, which is enabled by default for Linux/x86, 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.  This patch inserts a GNU_PROPERTY_X86_ISA_1_USED note if
> >> >> there may be no data sections before the text section so that the
> >> >> first PT_LOAD segment won't be code-only and will contain the program
> >> >> header.
> >> >
> >> >
> >> > i agree with Rich's comment on the bugzilla ticket:
> >> > simply always adding a .phdrs section that covers
> >> > the program headers would ensure that this kind of
> >> > bug is not introduced on other targets and seems
> >> > less hackish than adding a note.
> >>
> >> We can explore it.
> >>
> >> > i don't know why there is no such section already,
> >> > or if there is any drawback adding such a section,
> >> > is the requirement to access program headers in a
> >> > static linked executable a linux only thing?
> >>
> >> The program headers aren't required to be mapped into
> >> process image.  It may not be correct for Linux kermel
> >> to set AT_PHDR to an unmapped address.  But I'd like
> >> to support the existing kernel.  I am going to check in
> >> my change ASIS and backport it to 2.31 branch.
> >
> > They are required to be mapped, for at least these reasons:
> >
> > 1. PT_TLS is the only way the runtime can find the program's TLS
> >    image.
> >
> > 2. They're exposed as a public interface via dl_iterate_phdr, and the
> >    AT_PHDR auxv entry.
> 
> Only this one is relevant here.   The others don't need program headers
> mapped into process image.

Sure they do. Perhaps you're forgetting static linking. In the
dynamic-linked case, except for the main program, the dynamic linker
has access to the file and could load them and store them somewhere
other than mapped as part of a load segment. But for a static linked
program there is no access to the file available.

Rich

> > 3. PT_GNU_EH_FRAME is the way (or at least one of the ways) to find
> >    unwind information.
> >
> > 4. PT_LOAD segments are needed for dladdr to determine if an address
> >    is within the bounds of an object's memory.
> >
> > 5. PT_GNU_RELRO is necessary to mprotect the relro zone read-only
> >    after processing relocations.
> >
> > 6. PT_DYNAMIC is the way to find _DYNAMIC in a dynamic-linked program
> >    and the cleanest way to find the load address for static PIE
> >    programs.
> >
> > It's true that *some* of the things in the program headers are mainly
> > needed prior to passing control from the kernel into the mapped
> > program, but *a lot* are needed at runtime to implement important
> > features.
> >
> > Some of them could be replaced for static linking with auto-generated
> > symbols, but that's not existing practice, and it's probably good that
> > it's not since compilers will tend to make transformations that
> > invalidate start/end symbol hacks.
> >
> > Rich
> 
> 
> 
> -- 
> H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]