Date: Wed, 25 May 2011 15:44:02 -0400 From: John Baldwin <jhb@freebsd.org> To: Arnaud Lacombe <lacombar@gmail.com> Cc: freebsd-current@freebsd.org, Dimitry Andric <dim@freebsd.org> Subject: Re: [PATCH] Fix CFLAGS overwrite by Makefile Message-ID: <201105251544.02621.jhb@freebsd.org> In-Reply-To: <BANLkTin3aU2fO3WWO8knNeTjSVRgyYfU4w@mail.gmail.com> References: <1306267772-31084-1-git-send-email-lacombar@gmail.com> <201105251228.32399.jhb@freebsd.org> <BANLkTin3aU2fO3WWO8knNeTjSVRgyYfU4w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201105251544.02621.jhb>