Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2011 11:34:29 -0400
From:      Arnaud Lacombe <lacombar@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-current@freebsd.org, Dimitry Andric <dim@freebsd.org>
Subject:   Re: [PATCH] Fix CFLAGS overwrite by Makefile
Message-ID:  <BANLkTimzTGpS7zT1FC=AhHunQ-OQqThAUw@mail.gmail.com>
In-Reply-To: <201105250943.15362.jhb@freebsd.org>
References:  <1306267772-31084-1-git-send-email-lacombar@gmail.com> <4DDC17E5.2020700@FreeBSD.org> <BANLkTi=wbrvXHDiKix8DYYi9kjk5N-_vBw@mail.gmail.com> <201105250943.15362.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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=3Di386 and CPUTYPE=3Di586. This enforces
>> `-march=3Di586' 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. =A0You must have something wrong in your jail if you can't do a bui=
ldworld
> with CPUTYPE set to none and have it do the right thing. =A0You need to f=
ind
> your root problem. =A0Forcing 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=3Di586, produces i686
instructions which are incompatible with the target CPU.

 - Arnaud



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimzTGpS7zT1FC=AhHunQ-OQqThAUw>