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>