Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2011 17:30:37 -0400
From:      Arnaud Lacombe <lacombar@gmail.com>
To:        Dimitry Andric <dim@freebsd.org>
Cc:        current@freebsd.org
Subject:   Re: [PATCH] Fix CFLAGS overwrite by Makefile
Message-ID:  <BANLkTi=wbrvXHDiKix8DYYi9kjk5N-_vBw@mail.gmail.com>
In-Reply-To: <4DDC17E5.2020700@FreeBSD.org>
References:  <1306267772-31084-1-git-send-email-lacombar@gmail.com> <4DDC17E5.2020700@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Tue, May 24, 2011 at 4:41 PM, Dimitry Andric <dim@freebsd.org> wrote:
> On 2011-05-24 22:09, Arnaud Lacombe wrote:
>>
>> Many Makefile (espectially under sys/boot/) overwrite the value of CFLAGS.
>> This is an issue if you want to generate code for a specific CPU as before
>> the
>> Makefile is interpreted, CFLAGS might already have been set with CPU
>> specific
>> settings by<bsd.cpu.mk>, which is source from sys.mk.
>
> ...
>>
>> --- a/sys/boot/i386/boot2/Makefile
>> +++ b/sys/boot/i386/boot2/Makefile
>
> ...
>
> The problem with this patch is that for some of the things you fixed,
> stuff like boot-time programs, you NEVER want any CPU specific settings!
> You must use the default, lowest common denominator setting instead, or
> there is no guarantee the boot program will be correct.
>
To use your argument against you: with the default, the boot program
is not correct (see below).

> So that is why these Makefiles purposefully overwrite CFLAGS. it is not
> by accident.
You just might be right, but unless the code say the overwrite is
_on_purpose_, I would not assume the state of mind of the author, one
way or another.

> Besides, for space-constrained things like boot2, you
> might not even be able to compile it when using non-standard settings,
> since the code might grow too large.
>
or can shrink by using more optimized instructions.

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.

 - Arnaud

[0]: to sum up, unless error of my part, this is a canadian setup
where HOST=amd64, BUILD=i386 and TARGET=i586, and all hell breaks
loose because of COMPAT_FREEBSD32.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=wbrvXHDiKix8DYYi9kjk5N-_vBw>