explicit runtime loader segfaults under FreeBSD's Linux ABI

u-uclibc-y2lt at aetey.se u-uclibc-y2lt at aetey.se
Mon Nov 21 20:02:19 UTC 2011


Hello,

I realize this is not of "much interest" for the Linux-oriented
library. Nevertheless it is sometimes extremely useful to be able to run
the same binaries on a different kernel.

For quite fundamental reasons I depend on using the explicit runtime
loader. LD_LIBRARY_PATH does not do, nor the hardcoded loader path. That's
why I am so glad about the loader finally being present in uClibc.

This works fine for me on Linux.

At the same time, under FreeBSD's Linux ABI:

ld-uClibc.so.0 can be run and provides the expected diagnostics
("chances are you did not intend to run me" :)

Running programs using the hardcoded implicit loader works too.

Running "ld-uClibc.so.0 <binary>" segfaults quite early, before
accessing any other files than the <binary>.

Wonder if some of the gurus here would guess what might be the reason
and possibly even how to fix or to work around it.

glibc works fine with both the implicit and the explicit use of the loader.
It feels quite robust to run glibc-linked binaries under FreeBSD's Linux ABI.

I am using uClibc from git around 2011-09-15, it reports itself
as 0.9.33-git. The tests were done with FreeBSD 8.1 (Debian kFreeBSD)
and 9.0-RC2 (FreeBSD), with the same result.

(Linux and FreeBSD are 32-bit kernels running on Intel 686,
uClibc and the programs having been compiled for 486)

Comparing strace on Linux and ktrace on FreeBSD (omitted) output
while trying to run "ar" from gnu binutils, I can see the following:

-----------------------------------------------------------------------------
execve("/.../ld-uClibc.so.0", ["/.../ld-uClibc.so.0", "/.../ar"], .......
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1,
 0) = 0xb7f7c000
open("/.../ar", O_RDONLY) = 3
fstat(3, {st_dev=makedev(3, 1), st_ino=613642, st_mode=S_IFREG|0555, st_nlink=1,
 st_uid=2001, st_gid=2001, st_blksize=4096, st_blocks=936, st_size=471140, st_at
ime=2011/11/21-16:33:34, st_mtime=2011/11/19-21:47:37, st_ctime=2011/11/19-21:47
:38}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1,
 0) = 0xb7f7b000
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0p\226\4\0104\0\0\0\314,\
7\0\0\0\0\0004\0 \0\7\0(\0\27\0\26\0\6\0\0\0004\0\0\0004\200\4\0104\200\4\10\340
\0\0\0\340\0\0\0\5\0\0\0\4\0\0\0\3\0\0\0\24\1\0\0\24\201\4\10\24\201\4\10\37\0\0
\0\37\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\200\4\10\0\200\4\10T\27\7\0T\27\7\
0\5\0\0\0\0\20\0\0\1\0\0\0\0 \7\0\0\240\v\10\0\240\v\10P\6\0\0\334I\0\0\6\0\0\0"
..., 4096) = 4096
mmap2(0x8048000, 487424, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x804800
0
mmap2(0x8048000, 464724, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8
048000
mmap2(0x80ba000, 1616, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x72) = 0
x80ba000
mmap2(0x80bb000, 14812, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOU
S, -1, 0) = 0x80bb000
=====> Segfault under FreeBSD happens here, before/instead of close() <======
close(3)                                = 0
 ...
-----------------------------------------------------------------------------

Anybody who may suggest why?..

Thanks,
Rune



More information about the uClibc mailing list