Bug 162943 - uClibc explicit runtime loader segfaults under FreeBSD's Linux ABI
Summary: uClibc explicit runtime loader segfaults under FreeBSD's Linux ABI
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-emulation (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-29 08:50 UTC by Rune
Modified: 2020-10-14 16:36 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rune 2011-11-29 08:50:11 UTC
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 dynamic loader works too.

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

uClibc is 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.

The library is configured and compiled for Linux 2.4.19.
No problems detected running on various Linux kernels (2.6.x).

Strace output on Linux (ktrace from FreeBSD done and compared but not preserved)

Comparing strace on Linux and ktrace on FreeBSD (omitted) output
while trying to run "ar" from gnu binutils, compiled and linked with uClibc:
-----------------------------------------------------------------------------
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
 ...
-----------------------------------------------------------------------------

How-To-Repeat: Compile uClibc on Linux with support for dynamic linking and explicit runtime loader.
Run uClibc runtime loader with a binary (dynamically linked with uClibc) as the argument.
Comment 1 u-uclibc-byye 2012-07-25 14:19:49 UTC
Hello,

To make it clear that this is purely a FreeBSD issue:

The same test on
 NetBSD xdat05.ce.chalmers.se 5.1.1 NetBSD 5.1.1 (GENERIC) #0: Wed Jan  4 23:11:44 UTC 2012  builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-1-RELEASE/i386/201201040549Z-obj/home/builds/ab/netbsd-5-1-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386
 works fine.

Regards,
Rune
Comment 2 Pedro F. Giffuni freebsd_committer freebsd_triage 2014-08-23 15:44:40 UTC
Assign to maintainer.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:50:22 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 4 Pedro F. Giffuni freebsd_committer freebsd_triage 2018-05-28 19:57:07 UTC
(In reply to Eitan Adler from comment #3)
Is this really an issue anymore?