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. - ArnaudReceived on Wed May 25 2011 - 13:34:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC