Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2011 16:10:17 -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:  <BANLkTikOMtGqpSLeumR764AkwgB1N%2Bx_mA@mail.gmail.com>
In-Reply-To: <201105251544.02621.jhb@freebsd.org>
References:  <1306267772-31084-1-git-send-email-lacombar@gmail.com> <201105251228.32399.jhb@freebsd.org> <BANLkTin3aU2fO3WWO8knNeTjSVRgyYfU4w@mail.gmail.com> <201105251544.02621.jhb@freebsd.org>

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

On Wed, May 25, 2011 at 3:44 PM, John Baldwin <jhb@freebsd.org> wrote:
> 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 o=
ver
>> >> >> 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
>> > buildworld
>> >> > with CPUTYPE set to none and have it do the right thing. =A0You nee=
d to
> find
>> >> > 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.
>> >
>> > Huh? =A0GCC does not generate i686 instructions by default on FreeBSD/=
i386.
> =A0It
>> > 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 =A0[FreeBSD]
>>
>> # uname -a
>> FreeBSD build 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May =A01 07:18:07
>> UTC 2009 =A0 =A0 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENE=
RIC
>> =A0amd64
> =A0 ^^^^^
>
> I think this is probably going to confuse make and some other things as w=
ell.
>
This is what I meant when I said "canadian setup". HOST=3Damd64,
BUIILD=3Di386 and TARGET=3Di586.

I'm now trying to track down the original instruction triggering the
SIGILL, but it is in a library and that section of the memory does not
seem to be included in the core. Moreover I do not think I have any
way on a broken system to get the address at which libraries get
loaded (understand that ldd(1) is dynamically linked, and as the libc
the likely culprit, rendering ldd(1) useless).

 - Arnaud



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTikOMtGqpSLeumR764AkwgB1N%2Bx_mA>