Skip site navigation (1)Skip section navigation (2)
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>