Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Nov 2018 18:40:13 -0700
From:      Mark Millard <marklmi26-fbsd@yahoo.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        svn-src-head@freebsd.org
Subject:   Re: svn commit: r339876 - head/libexec/rtld-elf
Message-ID:  <E44F5772-1F8A-40B8-9C4E-B8362B768F37@yahoo.com>
In-Reply-To: <20181102004101.GI5335@kib.kiev.ua>
References:  <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com> <20181102004101.GI5335@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Nov-1, at 5:41 PM, Konstantin Belousov <kostikbel at gmail.com> =
wrote:

> 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 :
>>=20
>>> 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:
>>>>>=20
>>>>>> On 29. Oct 2018, at 22:08, Alex Richardson <arichardson at =
FreeBSD.org> wrote:
>>>>>>=20
>>>>>> Author: arichardson
>>>>>> Date: Mon Oct 29 21:08:02 2018
>>>>>> New Revision: 339876
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/339876
>>>>>>=20
>>>>>> Log:
>>>>>> rtld: set obj->textsize correctly
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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).
>>>>>=20
>>>>> Best regards
>>>>> Michael
>>>>=20
>>>> This is rather surprising since if anything the range of the icache
>>>> flush should increase rather than decrease after this change.
>>>>=20
>>>> 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?
>>>>=20
>>> Could it be that there is a hole between start of the object mapping =
and
>>> the last PT_LOADable segment eligible for execution ?
>>=20
>> [This note may be easier to deal with than the first
>> note that I sent out.]
>>=20
>> [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.]
>>=20
>> 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 :
>>=20
>> 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-
>=20
> 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.
>=20
> 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.

It will be a while before I can get an environment set
up which allows me to get a backtrace from a 32-bit
powerpc system. I have demonstrated that I get the crash
with what I tried to verify such.

I'll work on getting an environment in place that allows
what you are asking for.

Problem reproduction details (if you care) . . .

I've been trying to provide evidence but my 32-bit powerpc
environment is not as modern as has the problem. Also: the
buildworld it was installed from was built via clang, which
means that the libgcc_s.so that was built does not correctly
support C++ exceptions. (clang's generated output is the
source of that problem.) I did not build /libexec/gdb and
the /usr/local/gdb uses C++ exceptions heavily and will not
work.

All I can report for now is how I reproduced the problem. . .

# mkdir /339870
# cd /339870/

then I used wget to get:

=
https://artifact.ci.freebsd.org/snapshot/head/r339870/powerpc/powerpc/base=
*.txz

and expanded them in /339870/ and did:

# ./libexec/ld-elf.so.1 /bin/ls
Segmentation fault (core dumped)

Looking at where my environment is putting cores:

-rw-------  1 root  wheel     2752512 Nov  1 18:12:40 2018 =
/var/crash/ld-elf.so.1.9906.core

So at least I know the problem reproduces via such a
procedure.

For reference for the above:

# uname -apKU
FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r327364M  powerpc =
powerpc 1200054 1200054


=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E44F5772-1F8A-40B8-9C4E-B8362B768F37>