Date: Sat, 3 Nov 2018 13:02:55 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, Alexander Richardson <arichardson@freebsd.org> Subject: Re: svn commit: r339876 - head/libexec/rtld-elf Message-ID: <342280B4-75B9-48AA-926D-EF85FD6C3FE3@yahoo.com> In-Reply-To: <1AD60949-F621-4F24-8985-B02102824EB1@yahoo.com> References: <8E5A5F3A-F1A7-4702-A2F7-65D74CC5B2E5@yahoo.com> <20181102004101.GI5335@kib.kiev.ua> <E44F5772-1F8A-40B8-9C4E-B8362B768F37@yahoo.com> <003A49D7-6E8B-4775-A70B-E0EB44505D4B@yahoo.com> <20181102113827.GM5335@kib.kiev.ua> <7B29A4C8-228D-41CB-B594-98DFA456E9C8@yahoo.com> <20181102155234.GN5335@kib.kiev.ua> <E93B3880-281E-482C-9DA7-851398543B97@yahoo.com> <20181102185014.GP5335@kib.kiev.ua> <34554290-D26E-4FED-A598-4FB3E313EA92@yahoo.com> <20181103154955.GR5335@kib.kiev.ua> <1AD60949-F621-4F24-8985-B02102824EB1@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Nov-3, at 12:04 PM, Mark Millard <marklmi26-fbsd at yahoo.com> = wrote: > On 2018-Nov-3, at 8:49 AM, Konstantin Belousov <kostikbel at = gmail.com> wrote: >=20 >> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote: >>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov <kostikbel at = gmail.com> wrote: >>>=20 >>>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: >>>>> . . . >>>>=20 >>>> There seems to be an issue with the direct execution mode on ppc. >>>> Even otherwise working ld-elf.so.1 segfaults if I try to use it as >>>> standalone binary. >>>>=20 >>>> But if I specify patched ld-elf.so.1 as the interpreter for some = program, >>>> using 'cc -Wl,-I,<path>/ld-elf.so.1' it works. So I see there two = bugs, >>>> one is regression due to textsize calculation, which should be = fixed by >>>> my patch. Another is the direct exec problem. >>>=20 >>> My head -r339076 based powerpc64 and armv7 contexts also >>> fail for: >>>=20 >>> # /libexec/ld-elf.so.1 /bin/ls >>>=20 >>> The armv7 (a Cortext-A7 context) is interestingly different >>> in how it fails: >>>=20 >>> # /libexec/ld-elf.so.1 /bin/ls >>> ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot = allocate memory >> Can you show the ktrace/kdump for this ? >=20 > Sure, in the Cortex-A7 context . . . >=20 > . . . >=20 >=20 >>> My aarch64 context (a Cortext-A53 context) had no problem. >>>=20 >>> (All 3 examples are without any of the the recent updates >>> or patches to ld-elf.so.1 source code.) >>=20 >> And still, does the patch for isync range works ? You can test the = new >> ld-elf.so.1 standalone by hard-coding its path into the binary. = Build e.g. >> only ls(1) by using make in its directory, then re-issue the linking >> command with the additional flag '-Wl,-I,<path to patched = ld-elf.so.1> >> and try to run ls.full. >=20 > Looks like the old PowerMac is available again for > such activity. So I'll see about testing. I tried installing a buildworld that has the patches via using the make arguments: installworld distrib-dirs distribution DB_FROM_SRC=3D1 = DESTDIR=3D/usr/obj/DESTDIRs/gcc421-powerpc-installworld-poud (I normally have poudriere-devel use this = gcc421-powerpc-installworld-poud in this environment.) Then: # chroot /usr/obj/DESTDIRs/gcc421-powerpc-installworld-poud # pwd / # ls .cshrc COPYRIGHT boot etc libexec = mnt proc root tmp var .profile bin dev lib media = net rescue sbin usr # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/FBSDG4Srootfs 95203 38217 49369 44% / devfs 0 0 0 100% /dev # ls -lTd /bin/ls -r-xr-xr-x 1 root wheel 36816 Nov 3 19:19:26 2018 /bin/ls # ls -lTd /libexec/ld-elf.so.1* -r-xr-xr-x 1 root wheel 136100 Nov 3 19:17:53 2018 = /libexec/ld-elf.so.1 -r-xr-xr-x 1 root wheel 135932 Nov 2 02:10:34 2018 = /libexec/ld-elf.so.1.old # /usr/libexec/gdb /libexec/ld-elf.so.1 . . . (gdb) disass reloc_non_plt Dump of assembler code for function reloc_non_plt: . . . 0x00002b48 <reloc_non_plt+204>: bl 0xef78 <free> 0x00002b4c <reloc_non_plt+208>: lwz r31,64(r29) 0x00002b50 <reloc_non_plt+212>: lwz r9,68(r29) 0x00002b54 <reloc_non_plt+216>: mr r11,r31 0x00002b58 <reloc_non_plt+220>: add r0,r31,r9 0x00002b5c <reloc_non_plt+224>: cmplw cr7,r31,r0 0x00002b60 <reloc_non_plt+228>: blt+ cr7,0x2b78 <reloc_non_plt+252> 0x00002b64 <reloc_non_plt+232>: b 0x2bbc <reloc_non_plt+320> 0x00002b68 <reloc_non_plt+236>: addi r31,r31,32 0x00002b6c <reloc_non_plt+240>: add r0,r11,r9 0x00002b70 <reloc_non_plt+244>: cmplw cr7,r0,r31 0x00002b74 <reloc_non_plt+248>: ble- cr7,0x2bbc <reloc_non_plt+320> 0x00002b78 <reloc_non_plt+252>: lwz r0,0(r31) 0x00002b7c <reloc_non_plt+256>: cmpwi cr7,r0,1 0x00002b80 <reloc_non_plt+260>: bne+ cr7,0x2b68 <reloc_non_plt+236> 0x00002b84 <reloc_non_plt+264>: lwz r0,24(r31) 0x00002b88 <reloc_non_plt+268>: andi. r10,r0,1 ---Type <return> to continue, or q <return> to quit--- 0x00002b8c <reloc_non_plt+272>: beq+ 0x2b68 <reloc_non_plt+236> 0x00002b90 <reloc_non_plt+276>: lwz r0,52(r29) 0x00002b94 <reloc_non_plt+280>: lwz r3,8(r31) 0x00002b98 <reloc_non_plt+284>: lwz r4,20(r31) 0x00002b9c <reloc_non_plt+288>: addi r31,r31,32 0x00002ba0 <reloc_non_plt+292>: add r3,r0,r3 0x00002ba4 <reloc_non_plt+296>: bl 0x12858 <__syncicache> 0x00002ba8 <reloc_non_plt+300>: lwz r11,64(r29) 0x00002bac <reloc_non_plt+304>: lwz r9,68(r29) 0x00002bb0 <reloc_non_plt+308>: add r0,r11,r9 0x00002bb4 <reloc_non_plt+312>: cmplw cr7,r0,r31 0x00002bb8 <reloc_non_plt+316>: bgt+ cr7,0x2b78 <reloc_non_plt+252> . . . So, unless the chroot somehow bypasses use of that local /libexec/ld-elf.so.1 , the __synicache in a loop seems to be working under the chroot use. Let me know if this test is insufficient for some reason. =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?342280B4-75B9-48AA-926D-EF85FD6C3FE3>