Date: Fri, 2 Jun 1995 14:30:03 -0700 From: mpp@legarto.minn.net To: freebsd-bugs Subject: gnu/479: ld -s sometimes produces bad binaries. mmap problem? Message-ID: <199506022130.OAA15749@freefall.cdrom.com> In-Reply-To: Your message of Fri, 2 Jun 1995 16:07:09 -0500 <199506022107.QAA00881@mpp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Number: 479 >Category: gnu >Synopsis: ld -s sometimes produces bad binaries. mmap problem? >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 2 14:30:01 1995 >Originator: Mike Pritchard >Organization: >Release: FreeBSD BUILT-19950525 i386 >Environment: -current ld & kernel >Description: Various binaries dump core with "bus error" when linked with the -s option (strip the binary). Linking with -s doesn't always produce a bad binary. The resulting core file is not usable by gdb, and it reports that it is truncated. The core file is always 8192 bytes in length. This looks to be some type of kernel problem, possibly with mmap. Running "cmp binary.ld binary.strip" causes cmp to dump core with "bus error". Debugging the cmp core dump shows that it is failing when it tries to scan through the files after mmap'ing them. The binary stays unrunnable until a system reboot. After that the binary is just fine. Making a copy of the "bad" binary and trying to run that file will also work. I added a little bit of debug code to the coredump() routine in kern_sig.c to see why the core file doesn't get written out, and the following chunk of code gets an EFAULT error from the vn_rdwr routine. error = vn_rdwr(UIO_WRITE, vp, vm->vm_daddr, (int)ctob(vm->vm_dsize), (off_t)ctob(UPAGES), UIO_USERSPACE, IO_NODELOCKED|IO_UNIT, cred, (int *) NULL, p); The EFAULT above is probably that same reason why the binary fails in the first place. >How-To-Repeat: I was able to duplicate this with the "id" command, but your mileage may vary. I had to try out about 5 different small commands until I found a nice small one that would reproduce the problem. Once you find a binary that does fail, it will fail consistently. Linking with "-static" produces a good binary in the example below. Note: "cc -s -o..." below expands to: /usr/bin/ld -e start -dc -dp -o id -s /usr/lib/crt0.o id.o /usr/lib/libgcc.a -lc /usr/lib/libgcc.a Script started on Fri Jun 2 14:56:44 1995 mpp 1# cc -c id.c mpp 2# cc -o id id.o mpp 3# ./id uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 4# ls -l id -rwx--x--x 1 root wheel 13100 Jun 2 14:56 id* mpp 5# strip id mpp 6# ./id uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 7# ls -l id -rwx--x--x 1 root wheel 12288 Jun 2 14:57 id* mpp 8# cp id id.strip mpp 9# cc -s -o id id.o mpp 10# ./id Bus error mpp 11# ls -l id -rwx--x--x 1 root wheel 12288 Jun 2 14:57 id* mpp 12# cmp id id.strip Bus error (core dumped) mpp 13# cp id id.ld mpp 14# ./id.ld uid=0(root) gid=0(wheel) groups=0(wheel), ... mpp 15# cmp id.ld id.strip mpp 16# Script done on Fri Jun 2 14:58:12 1995 >Fix: None yet. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506022130.OAA15749>