Date: Sat, 3 Nov 2018 12:04:53 -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: <1AD60949-F621-4F24-8985-B02102824EB1@yahoo.com> In-Reply-To: <20181103154955.GR5335@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Nov-3, at 8:49 AM, Konstantin Belousov <kostikbel@gmail.com> =
wrote:
> 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 ?
Sure, in the Cortex-A7 context . . .
# ktrace -t+ /libexec/ld-elf.so.1 /bin/ls
ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot =
allocate memory
# kdump | less
80903 ktrace RET ktrace 0
80903 ktrace CALL execve(0xbfbfee23,0xbfbfecf0,0xbfbfecfc)
80903 ktrace NAMI "/libexec/ld-elf.so.1"
80903 ld-elf.so.1 RET execve JUSTRETURN
80903 ld-elf.so.1 CALL =
mmap(0,0x20000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xff=
ffffff,0,0,0)
80903 ld-elf.so.1 RET mmap 537071616/0x20031000
80903 ld-elf.so.1 CALL issetugid
80903 ld-elf.so.1 RET issetugid 0
80903 ld-elf.so.1 CALL =
openat(AT_FDCWD,0xbfbfee2d,0x300000<O_RDONLY|O_CLOEXEC|O_VERIFY>)
80903 ld-elf.so.1 NAMI "/bin/ls"
80903 ld-elf.so.1 RET openat 3
80903 ld-elf.so.1 CALL fstat(0x3,0xbfbfe638)
80903 ld-elf.so.1 STRU struct stat {dev=3D95, ino=3D2568217, =
mode=3D0100555, nlink=3D1, uid=3D0, gid=3D0, rdev=3D5140776, =
atime=3D1538464078.957949000, mtime=3D1538464078.958055000, =
ctime=3D1538464078.958810000, birthtime=3D1538464078.957947000, =
size=3D39440, blksize=3D32768, blocks=3D80, flags=3D0x0 }
80903 ld-elf.so.1 RET fstat 0
80903 ld-elf.so.1 CALL geteuid
80903 ld-elf.so.1 RET geteuid 0
80903 ld-elf.so.1 CALL =
mmap(0,0x1000,0x1<PROT_READ>,0x40002<MAP_PRIVATE|MAP_PREFAULT_READ>,0x3,0,=
0,0)
80903 ld-elf.so.1 RET mmap 537202688/0x20051000
80903 ld-elf.so.1 CALL =
mmap(0x10000,0xb000,0<PROT_NONE>,0x6010<MAP_FIXED|MAP_GUARD|MAP_EXCL>,0xff=
ffffff,0x10000,0,0)
80903 ld-elf.so.1 RET mmap -1 errno 12 Cannot allocate memory
80903 ld-elf.so.1 CALL munmap(0x20051000,0x1000)
80903 ld-elf.so.1 RET munmap 0
80903 ld-elf.so.1 CALL close(0x3)
80903 ld-elf.so.1 RET close 0
80903 ld-elf.so.1 CALL write(0x2,0x12e38,0xd)
80903 ld-elf.so.1 GIO fd 2 wrote 13 bytes
"ld-elf.so.1: "
80903 ld-elf.so.1 RET write 13/0xd
80903 ld-elf.so.1 CALL write(0x2,0x33238,0x44)
80903 ld-elf.so.1 GIO fd 2 wrote 68 bytes
"/bin/ls: mmap of entire address space failed: Cannot allocate =
memory"
80903 ld-elf.so.1 RET write 68/0x44
80903 ld-elf.so.1 CALL write(0x2,0xbfbfe1e7,0x1)
80903 ld-elf.so.1 GIO fd 2 wrote 1 byte
"
"
80903 ld-elf.so.1 RET write 1
80903 ld-elf.so.1 CALL exit(0x1)
>> 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.
Looks like the old PowerMac is available again for
such activity. So I'll see about testing.
=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?1AD60949-F621-4F24-8985-B02102824EB1>