From owner-freebsd-current@FreeBSD.ORG Sun Mar 21 11:00:19 2010 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 D1921106566B for ; Sun, 21 Mar 2010 11:00:19 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 626328FC08 for ; Sun, 21 Mar 2010 11:00:17 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,282,1267398000"; d="txt'?scan'208";a="28950065" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 21 Mar 2010 12:00:16 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5A46E1B0768; Sun, 21 Mar 2010 12:00:16 +0100 (CET) Date: Sun, 21 Mar 2010 12:00:09 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Garrett Cooper Message-ID: In-Reply-To: <7d6fde3d1003202147i1af5969bi333b58db6430c100@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100321110009f0889e84000039fe-a_best01+ Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update 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: Sun, 21 Mar 2010 11:00:19 -0000 This is a MIME encoded multipart message. --+permail-20100321110009f0889e84000039fe-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Cooper schrieb am 2010-03-21: > On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best > wrote: > > ok. i think i finally solved this riddle. the cause for the problem > > seems to > > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. > > actually i've > > been using the 'native' keyword for years now and never had any > > problems with > > it, but it seems a recent commit broke 'native' as CPUTYPE. for me > > this is > > 100% reproducable: > > 1. put 'CPUTYPE = native' in /etc/make.conf > > 2. build and install gnu/usr.bin/cc > > 3. do 'buildkernel' or 'buildworld' and observe the segfault. for > > some reason > > this always occurs in lib/libc/string/strlen.c (r205108). i've > > tested this > > with older version of libc.so (built 22. Feb) and got the same > > result. so i > > assume this is not a libc problem, but a problem with gcc tripping > > over some > > code in libc. i have no clue however why this happend just now and > > not > > earlier. i don't think there has been a recent commit to gcc. > > to solve this there are two ways: > > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let you > > compile > > everything just fine even with a gcc that has itself been built > > with 'CPUTYPE > > = native'. > > 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the > > gcc version > > that has been built this way will compile everything just fine even > > with > > 'CPUTYPE = native'. the only way to break this is to go and compile > > gcc again > > with the CPUTYPE set to 'native'. > > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to > > 'native' will > > give you a broken gcc! > What does -march=native yield in your case? There haven't been > any > recent commits to gcc, so I'm not sure whether or not that's the > issue. The libraries that I provided could have just been built from > a > sane system -- maybe it's something else that needs to be explored a > bit more closely to root cause the issue. i've experimented with setting CPUTYPE to native yesterday, but still couldn't figure out what the cause of it is. only a few points i'd like to point out: 1. this is very easily reproducible for me. i just need to set CPUTYPE=native in my /etc/make.conf and everything that gets linked against libc and uses the strlen() function won't compile due to gcc segfaulting. this is the case with /usr/src/bin/cat e.g. as well as kernel, world and probably lots of other stuff. also the following gcc command segfaults too (no need for setting CPUTYPE=native in this case, because -mtune gets set manually): gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 2. there seems to be a connection with strlen.c because gcc alaways segfaults here. also i've been using CPUTYPE=native for years now and never had any problems with it. for me the segfault always happens in: #0 strlen (str=Variable "str" is not available. ) at /usr/src/lib/libc/string/strlen.c:100 100 va = (*lp - mask01); it would be nice if people with arch i386 and amd64 could try to reproduce this (i believe the other archs don't support CPUTYPE=native). again the easiest way to trigger this (you don't need to edit your /etc/make.conf for this) should be running: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 for now i'm using the attached patch to prevent myself from shooting me in the foot again. ;) cheers. alex > Cheers, > -Garrett -- Alexander Best --+permail-20100321110009f0889e84000039fe-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="bsd.cpu.mk.patch.txt" SW5kZXg6IHNoYXJlL21rL2JzZC5jcHUubWsKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWsvYnNkLmNw dS5tawkocmV2aXNpb24gMjA1MzkwKQorKysgc2hhcmUvbWsvYnNkLmNwdS5tawkod29ya2luZyBj b3B5KQpAQCAtNTMsMTAgKzUzLDE2IEBACiBDUFVUWVBFID0gYXRobG9uLW1wCiAuICBlbGlmICR7 Q1BVVFlQRX0gPT0gIms3IgogQ1BVVFlQRSA9IGF0aGxvbgorI1hYWDogY29tcGlsaW5nIGdjYyB3 aXRoIC1tYXJjaD1uYXRpdmUgY2F1c2VzIGxpYmMgcHJvYmxlbXMKKy4gIGVsaWYgJHtDUFVUWVBF fSA9PSAibmF0aXZlIgorLmVycm9yIENQVVRZUEUgbmF0aXZlIGlzIG5vdCBzdXBwb3J0ZWQuCiAu ICBlbmRpZgogLiBlbGlmICR7TUFDSElORV9BUkNIfSA9PSAiYW1kNjQiCiAuICBpZiAke0NQVVRZ UEV9ID09ICJwcmVzY290dCIgfHwgJHtDUFVUWVBFfSA9PSAiY29yZTIiCiBDUFVUWVBFID0gbm9j b25hCisjWFhYOiBjb21waWxpbmcgZ2NjIHdpdGggLW1hcmNoPW5hdGl2ZSBjYXVzZXMgbGliYyBw cm9ibGVtcworLiAgZWxpZiAke0NQVVRZUEV9ID09ICJuYXRpdmUiCisuZXJyb3IgQ1BVVFlQRSBu YXRpdmUgaXMgbm90IHN1cHBvcnRlZC4KIC4gIGVuZGlmCiAuIGVuZGlmCiAK --+permail-20100321110009f0889e84000039fe-a_best01+--