Date: Fri, 25 Jul 1997 15:19:54 -0700 (PDT) From: Tom Bartol <bartol@salk.edu> To: Kyle Mestery <mestery@winternet.com> Cc: "Andreas S. Wetzel" <root@deadline.snafu.de>, current@FreeBSD.ORG Subject: Re: COMPAT_LINUX broken in -current? Message-ID: <Pine.BSF.3.95.970725141630.22341B-100000@pauling.salk.edu> In-Reply-To: <Pine.GSO.3.96.970725073327.17343A-100000@tundra.winternet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I too am seeing some anomalous behaviour in the linux emulator. I used to
be able (with 970209-SNAP I believe) to cross compile and then run linux
binaries on FreeBSD using gcc and friends from a linux slackware-3.0
machine (but libs from linux_lib-2.x). We needed to do this to compile
matlab .mex files (using linux matlab-4.2c). I was actually amazed that it
worked but very glad too because it meant that we could trade in our linux
machines for new and improved FreeBSD machines (FreeBSD performed 3.5x
faster than linux 2.0.28 and 2.5x faster than NT 4.0 running the same
matlab job under conditions of large memory usage and swapping, but I
digress). I could also cross compile ordinary C programs for linux and
run them perfectly under FreeBSD. The binaries generated would be
dynamically linked 32bit ELFs. However, that was then and this is now ;-)
The emulator now has the following behaviour:
I have a large C program which used to cross compile under the emulator
and run fine. It now cross compiles without errors but file says the
binary generated is statically linked. It seg faults and dumps core
immediately.
I have a small C program which behaved the same way as above but in my
efforts to solve the problem I replaced the /compat/linux tree with libs,
binaries, and includes obtained directly from a linux machine running
Debian Linux 1.2.7. This small C program now cross compiles to what file
says is a dynamically linked ELF and runs correctly. When I add the
-static flag to the cross compile I then get a statically linked binary
(which I had to `brandelf -t Linux` to run) and this binary seg faults and
dumps core. The large C program above would still only produce a
statically linked binary (according to file) even after my replacement for
the /compat/linux tree was installed.
When I compile both the large and small C programs either dynamically or
statically on a real Linux machine, they run just fine under FreeBSD.
I would really like for this to work again. I'm not a kernel hacker but
if I can be of assistance in tracking this down I would only be too
grateful... I've used ktrace to try to look at what's going on but I
didn't find the output very illuminating -- the seg fault occurs very
quickly:
23482 ktrace RET ktrace 0
23482 ktrace CALL execve(0xefbfd247,0xefbfd16c,0xefbfd174)
23482 ktrace NAMI "./l_calc"
23482 l_calc RET execve 0
23482 l_calc PSIG SIGSEGV SIG_DFL
23482 l_calc NAMI "l_calc.core"
The ktrace of the static binary compiled on a linux machine but run under
FreeBSD looks like:
23466 ktrace RET ktrace 0
23466 ktrace CALL execve(0xefbfd247,0xefbfd16c,0xefbfd174)
23466 ktrace NAMI "./l_calc"
23466 l_calc RET execve 0
23466 l_calc CALL mkdir(0)
23466 l_calc RET mkdir 0
23466 l_calc CALL old.sigvec(0x1,0xefbfcaf4)
23466 l_calc RET old.sigvec 0
23466 l_calc CALL dup2(0xefbfcab0)
23466 l_calc RET dup2 470196224/0x1c06a000
23466 l_calc CALL ioctl(0x1,0x5401 ,0xefbfcab8)
23466 l_calc RET ioctl 0
23466 l_calc CALL write(0x1,0x1c06a000,0x18)
23466 l_calc GIO fd 1 wrote 24 bytes
"Usage: l_calc ip_number
"
23466 l_calc RET write 24/0x18
23466 l_calc CALL exit(0x1)
Hope this helps a little,
Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970725141630.22341B-100000>