From owner-svn-src-head@freebsd.org Fri Nov 2 01:40:21 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A78410E06F6 for ; Fri, 2 Nov 2018 01:40:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23E1E70671 for ; Fri, 2 Nov 2018 01:40:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: pJpfLW8VM1mD7PMFBol4lRIzfLOkQ5u.YPu3OejVbJRDKTpdsK_iwxfd9KcQbZL dCu90ADoBla3GrSh8xalvPVai4m84F184Sdb8svnU7PWsvoFnCj8J8S_FXDJRbupJeLBCpqR1rcc hgUvMbkodSED1oKARc_GL1kY3GB3CYlMmJnK5.mQEC8XvT7fzYkfJGCmB6vQJuZoLwu_J7EtyoYz NNsTMaL54MQnRDo4NUIFqcrur.19Y9CqAnGddYTmu2O.FxatRMfMiKoq4arWF_VMYGBXodwkpu5i I7U6.Vk8tJo8YboAfEebwIDpF4zIQ_ITYq8TFyfsx4z1CnjUW0wS6Wp49PCTcOc35.3wKYOYQK.3 TRND35KtcoFKjVfcx2xRyyqY5649RuNwmcyOVd4iSrMhK3l2Og1.THYg6aWunHXLsK8JEmAxtyRO eVTJf.hBbQ4wb.39dg3OIi12GB9J446r0BQvsk5mwJ_j_kS_qmsLucCf7zu9euKWn9UzlkTIuS9a tqHN7vhIsTM5eXF0_Vf3c9AFaUj3a6DDb.6eIr0MPCg0GcAaPC__nYnu8PQDEFSmU4QZWWhIpUoL _t0aGEeBN2BEcTF8GErVbtsrmbkhonld_.1YxdAqUYbXHUZqSjTb.v3p4U0uW7NVPZ8MECjum5oX Rpso_.OG9lLCFqfhBAPbKA.teucEBvRiGI_q2cYZUfUKuJ_LGd2SFRKIuzfiGBwQ9Xjd0AD776i4 RLmhyS4jzVP4TfbeQbwkoUW32uNggIFVVJEfP8TK0SHb6cPQUBCHeOKwPlbUV651JEBO8NOlbJ6w uvQUmLR665y7U0NBNbnUdfmvtxHxGyq7wVc8yHCYUiHbParKaWhQMxYll8Fxaw2WKgf3u4On8MSC 4SF5vsOKakzhShv6Mym5c7xe3E26xU5rlXvvYcuGbEnmI0V4pDPkh843JctcF4Ae.C74ynQ2AqkL Wb78onPezqG4PB.EiMqug5vZEbHxAoZRSIqMT3VLAh_loF7l3BMw5NypmU0SbrrepAw8023lqCZW xEDWI_A09oJ88K38uIQ_WiXvMg6oA9_KJZegG2kfIF_edww4sCA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Fri, 2 Nov 2018 01:40:19 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e5e1254626b6eda75affef81b941fd0b; Fri, 02 Nov 2018 01:40:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r339876 - head/libexec/rtld-elf From: Mark Millard In-Reply-To: <20181102004101.GI5335@kib.kiev.ua> Date: Thu, 1 Nov 2018 18:40:13 -0700 Cc: svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com> <20181102004101.GI5335@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 01:40:21 -0000 On 2018-Nov-1, at 5:41 PM, Konstantin Belousov = 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 >>>> wrote: >>>>>=20 >>>>>> On 29. Oct 2018, at 22:08, Alex Richardson 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: > /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)