From owner-freebsd-current@FreeBSD.ORG Wed May 25 20:10:18 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993CA1065672; Wed, 25 May 2011 20:10:18 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 430008FC08; Wed, 25 May 2011 20:10:18 +0000 (UTC) Received: by iwn33 with SMTP id 33so17114iwn.13 for ; Wed, 25 May 2011 13:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sDYply9JuYG/gBaKUor9xu2Gd+cYZWj6dO0e+Nk89rM=; b=UayELTFALA/9pkzPv+zpg0WoVIlXw351/3SClOLNm7xauZqlQdU2UAEDAH6Z/zunqN BTxg5YUQUc6c0+dUgntSW2OK5xSkKeE3rjh/U9IopZ1fOKix2qFHYre9SmOUQewEjEjm 5IhzNL0OEMf8f0bCJXHY0RXNzVdnXZc/MoGaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sj9+18aDC8tnVX3lwhFvV6ZuN3bwSbt+4mlVMuewAuyATtXCfqrrxBwZRr3jmENLba /hZKbgS/d9VAY04Whzj+eVi44FvZah0Yqw+wO5ahIqZwrXglFKllbOJAICLbApfh79Ok NXMSKvEcKBQafYRMxV4hTBReutgPN3JemUu6g= MIME-Version: 1.0 Received: by 10.42.117.137 with SMTP id t9mr12749077icq.277.1306354217520; Wed, 25 May 2011 13:10:17 -0700 (PDT) Received: by 10.42.177.10 with HTTP; Wed, 25 May 2011 13:10:17 -0700 (PDT) In-Reply-To: <201105251544.02621.jhb@freebsd.org> References: <1306267772-31084-1-git-send-email-lacombar@gmail.com> <201105251228.32399.jhb@freebsd.org> <201105251544.02621.jhb@freebsd.org> Date: Wed, 25 May 2011 16:10:17 -0400 Message-ID: From: Arnaud Lacombe To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: [PATCH] Fix CFLAGS overwrite by Makefile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:10:18 -0000 Hi, On Wed, May 25, 2011 at 3:44 PM, John Baldwin 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 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 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