svn commit: r339876 - head/libexec/rtld-elf

[Konstantin Belousov]

On Tue, Oct 30, 2018 at 12:45:13PM -0700, Mark Millard wrote:
> Konstantin Belousov kostikbel at gmail.com wrote on
> Tue Oct 30 18:04:04 UTC 2018 :
> 
> > On Tue, Oct 30, 2018 at 03:32:40PM +0000, Alexander Richardson wrote:
> > > On Tue, 30 Oct 2018 at 10:17, Michael Tuexen
> > > <Michael.Tuexen at macmic.franken.de> wrote:
> > > >
> > > > > On 29. Oct 2018, at 22:08, Alex Richardson <arichardson at FreeBSD.org> wrote:
> > > > >
> > > > > Author: arichardson
> > > > > Date: Mon Oct 29 21:08:02 2018
> > > > > New Revision: 339876
> > > > > URL: https://svnweb.freebsd.org/changeset/base/339876
> > > > >
> > > > > Log:
> > > > >  rtld: set obj->textsize correctly
> > > > >
> > > > >  With lld-generated binaries the first PT_LOAD will usually be a read-only
> > > > >  segment unless you pass --no-rosegment. For those binaries the textsize is
> > > > >  determined by the next PT_LOAD. To allow both LLD and bfd 2.17 binaries to
> > > > >  be parsed correctly use the end of the last PT_LOAD that is marked as
> > > > >  executable instead.
> > > > >
> > > > >  I noticed that the value was wrong while adding some debug prints for some rtld
> > > > >  changes for CHERI binaries. `obj->textsize` only seems to be used by PPC so the
> > > > >  effect is untested. However, the value before was definitely wrong and the new
> > > > >  result matches the phdrs.
> > > > I build kernel and world with a revision later than this on a PPC. Buildword
> > > > ends up with a world where almost all binaries are segfaulting.... Especially gdb
> > > > (but svn, ls or so all segfault).
> > > >
> > > > Best regards
> > > > Michael
> > > 
> > > This is rather surprising since if anything the range of the icache
> > > flush should increase rather than decrease after this change.
> > > 
> > > I can only see this causing a behaviour change if we actually need to
> > > flush more than just the executable segments.
> > > Is it possible that some binary/library contains a non-executable
> > > segment as the first PT_LOAD?
> > > Or is there some linker script that adds custom PHDRS?
> > > 
> > Could it be that there is a hole between start of the object mapping and
> > the last PT_LOADable segment eligible for execution ?
> 
> [This note may be easier to deal with than the first
> note that I sent out.]
> 
> [My examples are from devel/powerpc64-xtoolchain-gcc used
> to buildworld buildkernel targeting a head -r339076 based
> powerpc64 environment. I do that on powerpc64 as well.]
> 
> powerpc64 loads the readonly data and the readonly code in one PT_LOAD,
> the first. The 2nd PT_LOAD is for sections without the readonly status,
> that includes .got and .plt being spanned. See below from
> objdump -ph for /bin/ls :
> 
> Program Header:
>     PHDR off    0x0000000000000040 vaddr 0x0000000010000040 paddr 0x0000000010000040 align 2**3
>          filesz 0x0000000000000188 memsz 0x0000000000000188 flags r--
>   INTERP off    0x00000000000001c8 vaddr 0x00000000100001c8 paddr 0x00000000100001c8 align 2**0
>          filesz 0x0000000000000015 memsz 0x0000000000000015 flags r--
>     LOAD off    0x0000000000000000 vaddr 0x0000000010000000 paddr 0x0000000010000000 align 2**16
>          filesz 0x000000000000910c memsz 0x000000000000910c flags r-x
>     LOAD off    0x0000000000009110 vaddr 0x0000000010019110 paddr 0x0000000010019110 align 2**16
>          filesz 0x0000000000000ee0 memsz 0x00000000000010e8 flags rw-
>  DYNAMIC off    0x0000000000009138 vaddr 0x0000000010019138 paddr 0x0000000010019138 align 2**3
>          filesz 0x00000000000001c0 memsz 0x00000000000001c0 flags rw-
>     NOTE off    0x00000000000001e0 vaddr 0x00000000100001e0 paddr 0x00000000100001e0 align 2**2
>          filesz 0x0000000000000030 memsz 0x0000000000000030 flags r--
>    STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
>          filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
We only need program headers, and we only need them from the object
which load causes the fault.  It might be not the binary but some library
that triggers the fault.  So the backtrace and some information from the
state of the image is needed.

You can build only rtld and use it as the standalone program to initiate
the image activation:
	<path>/ld-elf.so.1 /bin/ls
or similar.