Hi, On Wed, May 25, 2011 at 3:44 PM, John Baldwin <jhb_at_freebsd.org> wrote: > On Wednesday, May 25, 2011 1:03:10 pm Arnaud Lacombe wrote: >> Hi, >> >> On Wed, May 25, 2011 at 12:28 PM, John Baldwin <jhb_at_freebsd.org> wrote: >> > On Wednesday, May 25, 2011 11:34:29 am Arnaud Lacombe wrote: >> >> Hi, >> >> >> >> On Wed, May 25, 2011 at 9:43 AM, John Baldwin <jhb_at_freebsd.org> wrote: >> >> >> The original trouble I met, is that building for an i586 target in a >> >> >> 32bits jail, on top of an amd64 system[0] (I do not have control over >> >> >> that setup) produces incorrect binaries. The current fix I've got is >> >> >> to define MACHINE_ARCH=i386 and CPUTYPE=i586. This enforces >> >> >> `-march=i586' to be passed to the compiler, for all except the >> >> >> bootloader (because it overwrites CFLAGS). With this, binaries >> >> >> produced works fine (ie. /bin/sh no longer SIGILL when bringing up the >> >> >> system). So I suspect that gcc default to i686 in this setup and >> >> >> corrupt all the binaries, thus the attached patch. >> >> > >> >> > Wait. You must have something wrong in your jail if you can't do a >> > buildworld >> >> > with CPUTYPE set to none and have it do the right thing. You need to > find >> >> > your root problem. Forcing CPUCFLAGS for the boot code is a band-aid, >> > it's >> >> > not the right solution to your problem. >> >> > >> >> Unless error of my part, I never mentioned it was using `buildworld', >> >> which it is not. The system uses bare calls to make(1) in the >> >> sys/boot/ directory. As the jail is 32bits, it was expected not to be >> >> an issue, but the jail compiler uses /lib/libstand.a to link the >> >> loader, and it obviously contains i686-only instructions, which >> >> trigger a reset of an i586-only CPU. >> >> >> >> The more broad issue with the setup is that gcc within that >> >> environment, without being told -march=i586, produces i686 >> >> instructions which are incompatible with the target CPU. >> > >> > Huh? GCC does not generate i686 instructions by default on FreeBSD/i386. > It >> > generates i486 instructions but that is all. >> something is odd somewhere. >> >> > Are you sure you aren't running >> > the 64-bit gcc (which will generate i686 instructions by default)? >> > >> yes. >> >> # which gcc >> /usr/bin/gcc >> >> # file /usr/bin/gcc >> /usr/bin/gcc: ELF 32-bit LSB executable, Intel 80386, version 1 >> (FreeBSD), for FreeBSD 7.1, statically linked, FreeBSD-style, stripped >> >> # gcc -v >> Using built-in specs. >> Target: i386-undermydesk-freebsd >> Configured with: FreeBSD/i386 system compiler >> Thread model: posix >> gcc version 4.2.1 20070719 [FreeBSD] >> >> # uname -a >> FreeBSD build 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 >> UTC 2009 root_at_driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> amd64 > ^^^^^ > > I think this is probably going to confuse make and some other things as well. > This is what I meant when I said "canadian setup". HOST=amd64, BUIILD=i386 and TARGET=i586. I'm now trying to track down the original instruction triggering the SIGILL, but it is in a library and that section of the memory does not seem to be included in the core. Moreover I do not think I have any way on a broken system to get the address at which libraries get loaded (understand that ldd(1) is dynamically linked, and as the libc the likely culprit, rendering ldd(1) useless). - ArnaudReceived on Wed May 25 2011 - 18:10:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC