From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 13:17:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61ADF106566B for ; Sun, 4 Dec 2011 13:17:44 +0000 (UTC) (envelope-from joris.dedieu@gmail.com) Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 24DFA8FC08 for ; Sun, 4 Dec 2011 13:17:43 +0000 (UTC) Received: by qadb17 with SMTP id b17so1126543qad.13 for ; Sun, 04 Dec 2011 05:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=qBUhklPLqhOsZ6NrIVbHRF4p45Lg4W/Jfp3mLd2A5Do=; b=eOjmeS+hkg4Sz7dU/UKeaDAwVpokCBVtS0KmClnOZaeY3DS+m8JzSkusyhzNkSwAFx ByPGWBVWV2xOCZVg4gdlF9rIZ7eIPxV6/afDTzDEFuKVEMNi3Sk3FSsoWN8Nn8/HQtJ9 CvHXGVS2Eqn4jRuVGfT79TeSuCyz4WiNIO9c0= MIME-Version: 1.0 Received: by 10.224.116.144 with SMTP id m16mr4652349qaq.19.1323004663367; Sun, 04 Dec 2011 05:17:43 -0800 (PST) Received: by 10.229.93.211 with HTTP; Sun, 4 Dec 2011 05:17:43 -0800 (PST) In-Reply-To: <20111202164157.3058d91d@kan.dyndns.org> References: <20111202164157.3058d91d@kan.dyndns.org> Date: Sun, 4 Dec 2011 14:17:43 +0100 Message-ID: From: joris dedieu To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: rtld and noexec X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 13:17:44 -0000 2011/12/2 Alexander Kabaev : > On Fri, 2 Dec 2011 18:22:57 +0100 > joris dedieu wrote: > >> Hi, >> >> Here is a patch I use to prevent loading a shared object from a noexec >> mountpoint. =A0It's an easy way, I found, after the last root exploit >> ((http://seclists.org/fulldisclosure/2011/Nov/452), =A0to enhance =A0the >> security of my web servers (with /home, /tmp and /var/tmp mounted with >> noexec). >> >> - the last ftpd/porftpd =A0(libc ?) exploit does not work (indirect use >> of rtld via nsswitch) >> - the previous rtld security issue should have been more difficult to >> use in a noexec context. >> - It may help to prevent some miscellaneous usage of common softwares >> using dlopen like apache or php. >> >> I think it also makes sens because loading a shared object sounds like >> a kind of "execution". >> >> What do you think about this patch and the opportunity to open a PR on >> this subject? >> >> Cheers >> Joris >> >> >> --- libexec/rtld-elf/rtld.c.orig =A0 =A0 =A0 =A02011-12-02 12:09:40.0000= 00000 >> +0100 +++ libexec/rtld-elf/rtld.c =A0 =A0 2011-12-02 13:45:18.000000000 >> +0100 @@ -1123,32 +1123,50 @@ >> =A0{ >> =A0 =A0 =A0char *pathname; >> =A0 =A0 =A0char *name; >> + =A0 =A0struct statfs mnt; >> >> =A0 =A0 =A0if (strchr(xname, '/') !=3D NULL) { =A0/* Hard coded pathname= */ >> + =A0 =A0 =A0name =3D NULL; >> =A0 =A0 =A0 =A0 if (xname[0] !=3D '/' && !trust) { >> =A0 =A0 =A0 =A0 =A0 =A0 _rtld_error("Absolute pathname required for shar= ed object >> \"%s\"", xname); >> =A0 =A0 =A0 =A0 =A0 =A0 return NULL; >> =A0 =A0 =A0 =A0 } >> =A0 =A0 =A0 =A0 if (refobj !=3D NULL && refobj->z_origin) >> - =A0 =A0 =A0 =A0 =A0 return origin_subst(xname, refobj->origin_path); >> + =A0 =A0 =A0 =A0 =A0 pathname =3D origin_subst(xname, refobj->origin_pa= th); >> =A0 =A0 =A0 =A0 else >> - =A0 =A0 =A0 =A0 =A0 return xstrdup(xname); >> + =A0 =A0 =A0 =A0 =A0 pathname =3D xstrdup(xname); >> + =A0 =A0} >> + =A0 =A0else { /* xname is not a path */ >> + =A0 =A0 =A0 if (libmap_disable || (refobj =3D=3D NULL) || >> + =A0 =A0 =A0 =A0 =A0 (name =3D lm_find(refobj->path, xname)) =3D=3D NUL= L) >> + =A0 =A0 =A0 =A0 =A0 name =3D (char *)xname; >> + >> + =A0 =A0 =A0 dbg(" Searching for \"%s\"", name); >> + >> + =A0 =A0 =A0 pathname =3D search_library_path(name, ld_library_path); >> + =A0 =A0 =A0 if (pathname =3D=3D NULL && refobj !=3D NULL) >> + =A0 =A0 =A0 =A0 =A0 =A0pathname =3D search_library_path(name, refobj->= rpath); >> + =A0 =A0 =A0 if (pathname =3D=3D NULL) >> + =A0 =A0 =A0 =A0 =A0 =A0pathname =3D search_library_path(name, gethints= ()); >> + =A0 =A0 =A0 if (pathname =3D=3D NULL) >> + =A0 =A0 =A0 =A0 =A0 =A0pathname =3D search_library_path(name, >> STANDARD_LIBRARY_PATH); >> + =A0 =A0} >> + >> + =A0 =A0if (pathname !=3D NULL) { /* noexec mountpoint in pathname */ >> + =A0 =A0 =A0 if (statfs(pathname, &mnt) !=3D 0) >> + =A0 =A0 =A0 =A0 =A0 =A0free(pathname); >> + =A0 =A0 =A0 else { >> + =A0 =A0 =A0 =A0 =A0 =A0if (mnt.f_flags & MNT_NOEXEC) { >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0_rtld_error("noexec violation for shared ob= ject >> \"%s\"", pathname); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0free(pathname); >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL; >> + =A0 =A0 =A0 =A0 =A0 =A0} >> + =A0 =A0 =A0 =A0 =A0 =A0else >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0return pathname; >> + =A0 =A0 =A0 } >> =A0 =A0 =A0} >> >> - =A0 =A0if (libmap_disable || (refobj =3D=3D NULL) || >> - =A0 =A0 =A0 (name =3D lm_find(refobj->path, xname)) =3D=3D NULL) >> - =A0 =A0 =A0 name =3D (char *)xname; >> - >> - =A0 =A0dbg(" Searching for \"%s\"", name); >> - >> - =A0 =A0if ((pathname =3D search_library_path(name, ld_library_path)) != =3D >> NULL || >> - =A0 =A0 =A0(refobj !=3D NULL && >> - =A0 =A0 =A0(pathname =3D search_library_path(name, refobj->rpath)) != =3D NULL) >> || >> - =A0 =A0 =A0(pathname =3D search_library_path(name, gethints())) !=3D N= ULL || >> - =A0 =A0 =A0(pathname =3D search_library_path(name, >> STANDARD_LIBRARY_PATH)) !=3D NULL) >> - =A0 =A0 =A0 return pathname; >> - >> =A0 =A0 =A0if(refobj !=3D NULL && refobj->path !=3D NULL) { >> =A0 =A0 =A0 =A0 _rtld_error("Shared object \"%s\" not found, required by >> \"%s\"", name, basename(refobj->path)); >> _______________________________________________ > > > 1. There is a race using statfs and then loading the file. I will look at this point. Maybe statfs on the dirname ? > 2. We already have the check in do_load_object It doesn't work with dlopen. mount |grep tank/t tank/t on /tank/t (zfs, local, noexec, nfsv4acls) so /tank/t is noexec Here the powerful libmoo source code : void say_moo() { printf("mooooooooooooooooo\n"); } it's in /tank/t so noexec ls -l /tank/t/ total 6 -rwxr-xr-x 1 joris joris 4632 Dec 4 13:52 libmoo.so 1) First test with : main() { say_moo(); } LD_LIBRARY_PATH=3D/tank/t ./test_moo /libexec/ld-elf.so.1: Cannot execute objects on /tank/t Ok cool work has expected. Second test with : main() { void * handle =3D dlopen("/tank/t/libmoo.so", RTLD_LAZY); if (! handle) { fprintf(stderr, "%s\n", dlerror()); exit(1); } void (* moo) (void) =3D dlsym (handle, "say_moo"); (* moo)(); dlclose (handle); } ./test_moo mooooooooooooooooo Protection is not working when you use dlopen. This is what append with ftpd exploit . libc just load a shared object and the guy is root. Joris > > -- > Alexander Kabaev From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 14:31:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C14F1065677; Sun, 4 Dec 2011 14:31:47 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id A0B3F8FC1A; Sun, 4 Dec 2011 14:31:46 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 896E335AD6E; Sun, 4 Dec 2011 15:31:45 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 7111628468; Sun, 4 Dec 2011 15:31:45 +0100 (CET) Date: Sun, 4 Dec 2011 15:31:45 +0100 From: Jilles Tjoelker To: Mikolaj Golub Message-ID: <20111204143145.GA44832@stack.nl> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86aa8k2im0.fsf@kopusha.home.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 14:31:47 -0000 On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote: > [KERN_PROC_AUXV requires just p_cansee()] If we are ever going to do ASLR, the AUXV information tells an attacker where the stack, executable and RTLD are located, which defeats much of the point of randomizing the addresses in the first place. Given that the AUXV information seems to be used by debuggers only anyway, I think it would be good to move it to p_candebug() now. The full virtual memory maps (KERN_PROC_VMMAP, procstat -v) are already under p_candebug(). -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 15:57:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87873106566B; Sun, 4 Dec 2011 15:57:10 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 610798FC0C; Sun, 4 Dec 2011 15:57:10 +0000 (UTC) Received: from [192.168.2.115] (host86-161-238-124.range86-161.btcentralplus.com [86.161.238.124]) by cyrus.watson.org (Postfix) with ESMTPSA id 916BA46B0C; Sun, 4 Dec 2011 10:57:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20111204143145.GA44832@stack.nl> Date: Sun, 4 Dec 2011 15:57:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1E0AAB37-952A-49B4-94AF-B67B84E6957B@freebsd.org> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> <20111204143145.GA44832@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1084) Cc: Mikolaj Golub , Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 15:57:10 -0000 On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote: > On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote: >> [KERN_PROC_AUXV requires just p_cansee()] >=20 > If we are ever going to do ASLR, the AUXV information tells an = attacker > where the stack, executable and RTLD are located, which defeats much = of > the point of randomizing the addresses in the first place. >=20 > Given that the AUXV information seems to be used by debuggers only > anyway, I think it would be good to move it to p_candebug() now. >=20 > The full virtual memory maps (KERN_PROC_VMMAP, procstat -v) are = already > under p_candebug(). Agreed. In general, my view is that p_cansee() should be used for very = few of our process inspection APIs. I like your example of ASLR = especially, as it illustrates how debugging information can aid even = local attacks (i.e., user vs. setuid binary). Robert= From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 17:18:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3EB106564A for ; Sun, 4 Dec 2011 17:18:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7E79D8FC1D for ; Sun, 4 Dec 2011 17:18:29 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pB4HIPvs025374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Dec 2011 19:18:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pB4HIPSW098797; Sun, 4 Dec 2011 19:18:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pB4HIPN2098796; Sun, 4 Dec 2011 19:18:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Dec 2011 19:18:25 +0200 From: Kostik Belousov To: joris dedieu Message-ID: <20111204171825.GE50300@deviant.kiev.zoral.com.ua> References: <20111202164157.3058d91d@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vTAnc/q0mOWkBj2n" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers Subject: Re: rtld and noexec X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 17:18:30 -0000 --vTAnc/q0mOWkBj2n Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 04, 2011 at 02:17:43PM +0100, joris dedieu wrote: > 2011/12/2 Alexander Kabaev : > > On Fri, 2 Dec 2011 18:22:57 +0100 > > joris dedieu wrote: > > > >> Hi, > >> > >> Here is a patch I use to prevent loading a shared object from a noexec > >> mountpoint. =9AIt's an easy way, I found, after the last root exploit > >> ((http://seclists.org/fulldisclosure/2011/Nov/452), =9Ato enhance =9At= he > >> security of my web servers (with /home, /tmp and /var/tmp mounted with > >> noexec). > >> > >> - the last ftpd/porftpd =9A(libc ?) exploit does not work (indirect use > >> of rtld via nsswitch) > >> - the previous rtld security issue should have been more difficult to > >> use in a noexec context. > >> - It may help to prevent some miscellaneous usage of common softwares > >> using dlopen like apache or php. > >> > >> I think it also makes sens because loading a shared object sounds like > >> a kind of "execution". > >> > >> What do you think about this patch and the opportunity to open a PR on > >> this subject? > >> > >> Cheers > >> Joris > >> > >> > >> --- libexec/rtld-elf/rtld.c.orig =9A =9A =9A =9A2011-12-02 12:09:40.00= 0000000 > >> +0100 +++ libexec/rtld-elf/rtld.c =9A =9A 2011-12-02 13:45:18.000000000 > >> +0100 @@ -1123,32 +1123,50 @@ > >> =9A{ > >> =9A =9A =9Achar *pathname; > >> =9A =9A =9Achar *name; > >> + =9A =9Astruct statfs mnt; > >> > >> =9A =9A =9Aif (strchr(xname, '/') !=3D NULL) { =9A/* Hard coded pathna= me */ > >> + =9A =9A =9Aname =3D NULL; > >> =9A =9A =9A =9A if (xname[0] !=3D '/' && !trust) { > >> =9A =9A =9A =9A =9A =9A _rtld_error("Absolute pathname required for sh= ared object > >> \"%s\"", xname); > >> =9A =9A =9A =9A =9A =9A return NULL; > >> =9A =9A =9A =9A } > >> =9A =9A =9A =9A if (refobj !=3D NULL && refobj->z_origin) > >> - =9A =9A =9A =9A =9A return origin_subst(xname, refobj->origin_path); > >> + =9A =9A =9A =9A =9A pathname =3D origin_subst(xname, refobj->origin_= path); > >> =9A =9A =9A =9A else > >> - =9A =9A =9A =9A =9A return xstrdup(xname); > >> + =9A =9A =9A =9A =9A pathname =3D xstrdup(xname); > >> + =9A =9A} > >> + =9A =9Aelse { /* xname is not a path */ > >> + =9A =9A =9A if (libmap_disable || (refobj =3D=3D NULL) || > >> + =9A =9A =9A =9A =9A (name =3D lm_find(refobj->path, xname)) =3D=3D N= ULL) > >> + =9A =9A =9A =9A =9A name =3D (char *)xname; > >> + > >> + =9A =9A =9A dbg(" Searching for \"%s\"", name); > >> + > >> + =9A =9A =9A pathname =3D search_library_path(name, ld_library_path); > >> + =9A =9A =9A if (pathname =3D=3D NULL && refobj !=3D NULL) > >> + =9A =9A =9A =9A =9A =9Apathname =3D search_library_path(name, refobj= ->rpath); > >> + =9A =9A =9A if (pathname =3D=3D NULL) > >> + =9A =9A =9A =9A =9A =9Apathname =3D search_library_path(name, gethin= ts()); > >> + =9A =9A =9A if (pathname =3D=3D NULL) > >> + =9A =9A =9A =9A =9A =9Apathname =3D search_library_path(name, > >> STANDARD_LIBRARY_PATH); > >> + =9A =9A} > >> + > >> + =9A =9Aif (pathname !=3D NULL) { /* noexec mountpoint in pathname */ > >> + =9A =9A =9A if (statfs(pathname, &mnt) !=3D 0) > >> + =9A =9A =9A =9A =9A =9Afree(pathname); > >> + =9A =9A =9A else { > >> + =9A =9A =9A =9A =9A =9Aif (mnt.f_flags & MNT_NOEXEC) { > >> + =9A =9A =9A =9A =9A =9A =9A_rtld_error("noexec violation for shared = object > >> \"%s\"", pathname); > >> + =9A =9A =9A =9A =9A =9A =9Afree(pathname); > >> + =9A =9A =9A =9A =9A =9A =9Areturn NULL; > >> + =9A =9A =9A =9A =9A =9A} > >> + =9A =9A =9A =9A =9A =9Aelse > >> + =9A =9A =9A =9A =9A =9A =9Areturn pathname; > >> + =9A =9A =9A } > >> =9A =9A =9A} > >> > >> - =9A =9Aif (libmap_disable || (refobj =3D=3D NULL) || > >> - =9A =9A =9A (name =3D lm_find(refobj->path, xname)) =3D=3D NULL) > >> - =9A =9A =9A name =3D (char *)xname; > >> - > >> - =9A =9Adbg(" Searching for \"%s\"", name); > >> - > >> - =9A =9Aif ((pathname =3D search_library_path(name, ld_library_path))= !=3D > >> NULL || > >> - =9A =9A =9A(refobj !=3D NULL && > >> - =9A =9A =9A(pathname =3D search_library_path(name, refobj->rpath)) != =3D NULL) > >> || > >> - =9A =9A =9A(pathname =3D search_library_path(name, gethints())) !=3D= NULL || > >> - =9A =9A =9A(pathname =3D search_library_path(name, > >> STANDARD_LIBRARY_PATH)) !=3D NULL) > >> - =9A =9A =9A return pathname; > >> - > >> =9A =9A =9Aif(refobj !=3D NULL && refobj->path !=3D NULL) { > >> =9A =9A =9A =9A _rtld_error("Shared object \"%s\" not found, required = by > >> \"%s\"", name, basename(refobj->path)); > >> _______________________________________________ > > > > > > 1. There is a race using statfs and then loading the file. > I will look at this point. Maybe statfs on the dirname ? >=20 > > 2. We already have the check in do_load_object > It doesn't work with dlopen. >=20 > mount |grep tank/t > tank/t on /tank/t (zfs, local, noexec, nfsv4acls) >=20 > so /tank/t is noexec >=20 > Here the powerful libmoo source code : >=20 > void say_moo() { > printf("mooooooooooooooooo\n"); > } >=20 > it's in /tank/t so noexec >=20 > ls -l /tank/t/ > total 6 > -rwxr-xr-x 1 joris joris 4632 Dec 4 13:52 libmoo.so >=20 > 1) First test with : >=20 > main() { > say_moo(); > } >=20 > LD_LIBRARY_PATH=3D/tank/t ./test_moo > /libexec/ld-elf.so.1: Cannot execute objects on /tank/t >=20 > Ok cool work has expected. >=20 > Second test with : >=20 > main() { > void * handle =3D dlopen("/tank/t/libmoo.so", RTLD_LAZY); > if (! handle) { > fprintf(stderr, "%s\n", dlerror()); > exit(1); > } > void (* moo) (void) =3D dlsym (handle, "say_moo"); > (* moo)(); > dlclose (handle); > } >=20 > ./test_moo > mooooooooooooooooo >=20 > Protection is not working when you use dlopen. This is what append > with ftpd exploit . libc just load a shared object and the guy is > root. If you started to change rtld code, it pays to read it first. The first example worked only because you used LD_LIBRARY_PATH. See r144062. It has nothing to do with dlopen/static linking. I do not think you patch is a right thing to do. noexec check is a hack anyway, because noexec _mount_ option is only there to globally disable execve(2) from the mount point, and not to disable mapping with PROT_EXEC. rtld does not provide any magic from the kernel POV, so purposive person can re-implement it at will in her code. --vTAnc/q0mOWkBj2n Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7bq2EACgkQC3+MBN1Mb4ibhACbBNS8aLZJZjDoxbCTLH+tgRnQ 4U4An3t/Owe0k5gK3w1hwZm1/mrWjEyF =4WPM -----END PGP SIGNATURE----- --vTAnc/q0mOWkBj2n-- From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 17:55:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6117B106564A; Sun, 4 Dec 2011 17:55:33 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 901828FC16; Sun, 4 Dec 2011 17:55:32 +0000 (UTC) Received: by bkat2 with SMTP id t2so6715585bka.13 for ; Sun, 04 Dec 2011 09:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=Z+ORSDHWXWqHyCJjsdYVlSD6Zznk5CxfA+Bsaxq7JjE=; b=r53wmzMUvfXia8MZSW7CMMTvyz1u4tL8JlSaRHaCF9Qgir6iD2vEmLzTxcQZv4Exve HTiUJObim6jQ1YOdvAB7dFUebT9IUjgHoc5ETQqStIf0mwgtLYji1OcwLlpnQrmMGw61 BJsrgPHey/H9mADhIX9omxwimPyG+BUFYAbUk= Received: by 10.205.128.148 with SMTP id he20mr2725898bkc.127.1323021331231; Sun, 04 Dec 2011 09:55:31 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id e8sm26023468bkd.7.2011.12.04.09.55.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Dec 2011 09:55:29 -0800 (PST) From: Mikolaj Golub To: "Robert N. M. Watson" References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> <20111204143145.GA44832@stack.nl> <1E0AAB37-952A-49B4-94AF-B67B84E6957B@freebsd.org> X-Comment-To: Robert N. M. Watson Sender: Mikolaj Golub Date: Sun, 04 Dec 2011 19:55:27 +0200 In-Reply-To: <1E0AAB37-952A-49B4-94AF-B67B84E6957B@freebsd.org> (Robert N. M. Watson's message of "Sun, 4 Dec 2011 15:57:06 +0000") Message-ID: <86r50kdxww.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 17:55:33 -0000 On Sun, 4 Dec 2011 15:57:06 +0000 Robert N. M. Watson wrote: RNMW> On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote: >> On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote: >>> [KERN_PROC_AUXV requires just p_cansee()] >> >> If we are ever going to do ASLR, the AUXV information tells an attacker >> where the stack, executable and RTLD are located, which defeats much of >> the point of randomizing the addresses in the first place. >> >> Given that the AUXV information seems to be used by debuggers only >> anyway, I think it would be good to move it to p_candebug() now. >> >> The full virtual memory maps (KERN_PROC_VMMAP, procstat -v) are already >> under p_candebug(). RNMW> Agreed. In general, my view is that p_cansee() should be used for very RNMW> few of our process inspection APIs. I like your example of ASLR RNMW> especially, as it illustrates how debugging information can aid even RNMW> local attacks (i.e., user vs. setuid binary). Thanks! I will change it to p_candebug(). -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 20:58:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F7071065677; Sun, 4 Dec 2011 20:58:18 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 671058FC20; Sun, 4 Dec 2011 20:58:17 +0000 (UTC) Received: by bkat2 with SMTP id t2so6826832bka.13 for ; Sun, 04 Dec 2011 12:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:message-id :user-agent:mime-version:content-type; bh=rm+XDrH0GyBfbqFZWfycKF92w6bq8R+JYFiQoCnFJPA=; b=C+NhcS0aUkRQjeZM2NewAUkHNcL1Mt8H06nSEALrYtyFuxPLlDIhMcSsii/a2gvO1v vkkvjQTQi+xl/NXBjwj9IUu3Qvyl6uVP/CksDL4yDi3pbY5WHTbRQSm9VlHYc/Mh6aVn l3+Ul2utrbSObB9RIVIyXVzbyVCOJ70h2cePg= Received: by 10.204.136.193 with SMTP id s1mr3102255bkt.111.1323032295773; Sun, 04 Dec 2011 12:58:15 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id w3sm18308101bkq.3.2011.12.04.12.58.13 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Dec 2011 12:58:14 -0800 (PST) From: Mikolaj Golub To: "Robert N. M. Watson" References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> <20111204143145.GA44832@stack.nl> <1E0AAB37-952A-49B4-94AF-B67B84E6957B@freebsd.org> X-Comment-To: Robert N. M. Watson Sender: Mikolaj Golub Date: Sun, 04 Dec 2011 22:58:10 +0200 Message-ID: <86liqsawbh.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , freebsd-hackers@freebsd.org, Jilles Tjoelker Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 20:58:18 -0000 On Sun, 4 Dec 2011 15:57:06 +0000 Robert N. M. Watson wrote: RNMW> On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote: >> On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote: >>> [KERN_PROC_AUXV requires just p_cansee()] >> >> If we are ever going to do ASLR, the AUXV information tells an attacker >> where the stack, executable and RTLD are located, which defeats much of >> the point of randomizing the addresses in the first place. >> >> Given that the AUXV information seems to be used by debuggers only >> anyway, I think it would be good to move it to p_candebug() now. >> >> The full virtual memory maps (KERN_PROC_VMMAP, procstat -v) are already >> under p_candebug(). RNMW> Agreed. In general, my view is that p_cansee() should be used for very RNMW> few of our process inspection APIs. I like your example of ASLR RNMW> especially, as it illustrates how debugging information can aid even RNMW> local attacks (i.e., user vs. setuid binary). What do you think about recently added kern.proc.ps_strings, which returns location of ps_strings structure? It uses p_cansee() too. The location is the same for all processes of the same ABI, so this does not look like sensitive information, on the other hand it also seems to be used by debuggers only. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 21:19:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE7D106566C; Sun, 4 Dec 2011 21:19:18 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 10C478FC0C; Sun, 4 Dec 2011 21:19:18 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 153B31DECF6; Sun, 4 Dec 2011 22:19:16 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id F170C28468; Sun, 4 Dec 2011 22:19:15 +0100 (CET) Date: Sun, 4 Dec 2011 22:19:15 +0100 From: Jilles Tjoelker To: Mikolaj Golub Message-ID: <20111204211915.GA46340@stack.nl> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> <86aa8k2im0.fsf@kopusha.home.net> <20111204143145.GA44832@stack.nl> <1E0AAB37-952A-49B4-94AF-B67B84E6957B@freebsd.org> <86liqsawbh.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86liqsawbh.fsf@kopusha.home.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kostik Belousov , freebsd-hackers@freebsd.org, "Robert N. M. Watson" Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 21:19:18 -0000 On Sun, Dec 04, 2011 at 10:58:10PM +0200, Mikolaj Golub wrote: > RNMW> Agreed. In general, my view is that p_cansee() should be used for very > RNMW> few of our process inspection APIs. I like your example of ASLR > RNMW> especially, as it illustrates how debugging information can aid even > RNMW> local attacks (i.e., user vs. setuid binary). > What do you think about recently added kern.proc.ps_strings, which > returns location of ps_strings structure? It uses p_cansee() too. The > location is the same for all processes of the same ABI, so this does > not look like sensitive information, on the other hand it also seems > to be used by debuggers only. With stack ASLR, the address will not be the same for every process of the same ABI and will be sensitive information. Therefore I think this should be locked down too. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 22:03:21 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA981065670 for ; Sun, 4 Dec 2011 22:03:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 41A158FC0C for ; Sun, 4 Dec 2011 22:03:20 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA00497; Mon, 05 Dec 2011 00:03:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXK9V-000I7S-NH; Mon, 05 Dec 2011 00:03:17 +0200 Message-ID: <4EDBEE25.9050008@FreeBSD.org> Date: Mon, 05 Dec 2011 00:03:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Hartland References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk> <4ED8E9D0.4070006@FreeBSD.org> <2537A2099932494E9E7019B53EBDAA34@multiplay.co.uk> In-Reply-To: <2537A2099932494E9E7019B53EBDAA34@multiplay.co.uk> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:03:22 -0000 on 02/12/2011 19:13 Steven Hartland said the following: [snip] > Given this starting point the following links provided me with addtional > information:- > http://www.freebsd.org/doc/en/books/arch-handbook/vm.html > http://www.freebsd.org/doc/en/books/design-44bsd/overview-memory-management.html > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/ > http://www.cse.chalmers.se/edu/course/EDA203/unix4.pdf > > I was under the incorrect impression that Virtual Memory (VM) was so named as it > was a unified physical memory and swap (virtual memory), but its not that simple, > as other items such as file-backed objects also count to this total which would > never show in physical or swap allocation of other tools such as top and swapinfo. > > So what I believe is now the big cause of virtual memory uplift vs the memory > totals shown by ps / top is that the vm totals include things like file backed > memory mapped process binaries, shared libs etc many multiple times. > > This would explain why this specific machine shows the applification more than > others here as it runs thousands of very small lightweight processes. > > Thanks for pointer Andy, I now understand a lot more about the BSD VMS :) > > What do people think about expanding that entry in the man page of vmstat to > clarify just what active "virtual pages" really means? Thank you for the excellent additional research. I think that the expanded explanation would be very appreciated, but only if it is completely correct and unambiguous from technical perspective. That might not be trivial to achieve, but is realistic :-) P.S. I think that it would also be nice to further breakdown VM stats by type of object e.g. anonymous (swap-backed) memory vs file-backed backed memory, etc. Proportional RSS reporting is another nice to have feature. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 22:22:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0A5D61065672; Sun, 4 Dec 2011 22:22:03 +0000 (UTC) Date: Sun, 4 Dec 2011 22:22:03 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111204222203.GA8898@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 22:22:03 -0000 hi there, i was going through the clang warnings from a GENERIC buildkernel and noticed the following: ===> drm/mga (all) /usr/subversion-src/sys/modules/drm/mga/../../../dev/drm/mga_state.c:56:2: error: invalid conversion specifier 'Z' [-Werror,-Wformat-invalid-specifier] BEGIN_DMA(2); ^~~~~~~~~~~ @/dev/drm/mga_drv.h:291:35: note: expanded from: DRM_INFO( " space=0x%x req=0x%Zx\n", \ ^ @/dev/drm/drmP.h:317:60: note: expanded from: #define DRM_INFO(fmt, ...) printf("info: [" DRM_NAME "] " fmt , ##__VA_ARGS__) ^ these lines should cover all warnings: otaku% egrep -r "%[0-9]*Zx" /usr/src/sys/dev/drm dev/drm/mga_drv.h: DRM_INFO( " space=0x%x req=0x%Zx\n", \ dev/drm/mga_drv.h: DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04Zx\n", \ ... i couldn't find a reference to an upercase "Z" in the printf(9) man page. i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might come from linux'es libc5 and is the equaivalent to glibc's "z". can we adjust those lines, so the clang warnings disappear? cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 23:37:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56ACC1065670 for ; Sun, 4 Dec 2011 23:37:01 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDBA8FC12 for ; Sun, 4 Dec 2011 23:37:00 +0000 (UTC) Received: by ggnp1 with SMTP id p1so2287889ggn.13 for ; Sun, 04 Dec 2011 15:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=laLckvusYLfORwFzI9g8ZCETtY1dlF3u3Zvxiuyt0Lg=; b=ue55FqVuAmXHqq59HIjHzM0lAJgRvWstZY/rV2N/38gU1dDHpoqI/nqdQwrO6w3jgU Rvxk/U94zjcqVoyfiSCn0H8U+7fmtXbeXTnLSoqR1g8XlEX7TiHje0toos16zY1dri3c d4KWQ/Qp7/+6dWEjy4bCYz8K/jb3lkKZYF6MM= MIME-Version: 1.0 Received: by 10.182.180.5 with SMTP id dk5mr1271114obc.7.1323040171314; Sun, 04 Dec 2011 15:09:31 -0800 (PST) Received: by 10.182.47.38 with HTTP; Sun, 4 Dec 2011 15:09:31 -0800 (PST) Date: Mon, 5 Dec 2011 00:09:31 +0100 Message-ID: From: Oliver Pinter To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Flash FS for NetBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 23:37:01 -0000 Hi all! Today found this procejt: http://chewiefs.sed.hu/ When I good remember, Arounld searched flash fs for bsd, so cc-d. From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 4 23:42:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0AA8106564A for ; Sun, 4 Dec 2011 23:42:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF5D8FC0C for ; Sun, 4 Dec 2011 23:42:39 +0000 (UTC) Received: by wgbds13 with SMTP id ds13so5568754wgb.1 for ; Sun, 04 Dec 2011 15:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=o/awoNEyrw0qT9ZU09pQNr2IuWzqo6J+dpN5tNwkQMA=; b=ahqH9Bo04++WR2PZy/Ae5CSvWWlN6U4f1JnsOTWBT/gOJfACtn/CquKnpIEPe2wZUq U9Nf2r/Rlb5iwelUyQE2uEeKOYzuuNB8ZsZmbkuLBDcmySH2CcynBe+HNhQ+YbpR4aU8 0bTdydsW63r1Ya8omYgpLqL7Q5KSFW3abI08U= MIME-Version: 1.0 Received: by 10.180.104.35 with SMTP id gb3mr10485793wib.11.1323042158120; Sun, 04 Dec 2011 15:42:38 -0800 (PST) Received: by 10.180.94.2 with HTTP; Sun, 4 Dec 2011 15:42:38 -0800 (PST) In-Reply-To: <20111007102841.GG26743@acme.spoerlein.net> References: <4E712D11.7040202@FreeBSD.org> <4E75B67E.1000802@FreeBSD.org> <20110922190535.GR26743@acme.spoerlein.net> <20110922212602.GS26743@acme.spoerlein.net> <20111007102841.GG26743@acme.spoerlein.net> Date: Sun, 4 Dec 2011 18:42:38 -0500 Message-ID: From: Arnaud Lacombe To: Arnaud Lacombe , hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 23:42:39 -0000 Hi, On Fri, Oct 7, 2011 at 6:28 AM, Ulrich Sp=F6rlein wrote= : > On Fri, 2011-09-30 at 15:41:41 -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 26, 2011 at 2:23 PM, Arnaud Lacombe wro= te: >> > Hi, >> > >> > On Thu, Sep 22, 2011 at 5:26 PM, Ulrich Sp=F6rlein = wrote: >> >> On Thu, 2011-09-22 at 15:52:43 -0400, Arnaud Lacombe wrote: >> >>> Hi, >> >>> >> >>> On Thu, Sep 22, 2011 at 3:05 PM, Ulrich Sp=F6rlein wrote: >> >>> > On Sun, 2011-09-18 at 12:14:38 +0300, Andriy Gapon wrote: >> >>> >> >> >>> >> Just decided to follow the global trends and trying to throw all = of my >> >>> >> local/private changes at you in hope that the "crowd-sourcing mag= ic" might >> >>> >> somehow happen :-) =A0This seems definitely easier than carefully= producing the >> >>> >> patch files and keeping them up-to-date. >> >>> >> >> >>> >> So, my newly cloned gitorious repository: >> >>> >> https://gitorious.org/~avg/freebsd/avgbsd >> >>> >> >> >>> >> And the first branch of interest: >> >>> >> https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 >> >>> > >> >>> > I'll throw mine in as well: >> >>> > >> >>> > https://github.com/uqs/freebsd-head/branches >> >>> > >> >>> is that the same as tree as Fabien's, or a new snapshot ? >> >>> >> >>> If not, couldn't we agree to have all the same tree in order to ease >> >>> code sharing between all of them ? >> >>> >> >>> I see there is already a https://github.com/freebsd/freebsd tree, >> >>> which seem different than Fabien's tree on github. It really look li= ke >> >>> The FreeBSD Project (https://github.com/freebsd/) is not able to >> >>> provide consistency. >> >> >> >> The freebsd-head tree is the same that everybody in the world can get= by >> >> simply running git svn clone against the FreeBSD subversion server >> >> (you'd need a lot of patience, though). >> >> >> > FWIW, how comes that there is not yet any `stable/9' branch on the git= hub tree ? >> > >> Ulrich, ping ? > > Oops, sorry for the delay! Fixed now, thanks for bringing it to my > attention. I missed the push --all flag. :/ > FWIW, the github mirror[0] of the completed SVN tree has not seen any upgrade for a week now. Did some script broke ? Thanks, - Arnaud [0]: https://github.com/freebsd/freebsd From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 12:50:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0FF0106566B for ; Mon, 5 Dec 2011 12:50:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id AD5758FC13 for ; Mon, 5 Dec 2011 12:50:13 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so6191698vcb.13 for ; Mon, 05 Dec 2011 04:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2eCeZYFW84DzRZzA8XJK6k+Ms1MRHTpJOzTjxFJ4zew=; b=Tzw5ah+LLRUUMB8Xrzp6JJMs650lZvGdJsLGQ/uyjXx/N1+P0pcxpOg3VUKMsAS1gH kQE3nSrHs/vkWghJwjQee95rGLT/Tba1jxlf4RjMd6mtlp7wrpdzLv0x96GLaAWmey7y 8wpYF2OVllU4I908krwjU1l0ekxyVcZuqeMFQ= MIME-Version: 1.0 Received: by 10.52.94.227 with SMTP id df3mr5019965vdb.51.1323089410241; Mon, 05 Dec 2011 04:50:10 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.109.10 with HTTP; Mon, 5 Dec 2011 04:50:10 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Dec 2011 20:50:10 +0800 X-Google-Sender-Auth: BCuZMI9XrvsnJNj1J9f14S3B0oo Message-ID: From: Adrian Chadd To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Flash FS for NetBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 12:50:14 -0000 On 5 December 2011 07:09, Oliver Pinter wrote: > Hi all! > > Today found this procejt: > http://chewiefs.sed.hu/ > > When I good remember, Arounld searched flash fs for bsd, so cc-d. hah. port away! :) adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 13:39:03 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4F21065673; Mon, 5 Dec 2011 13:39:03 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DDBA8FC0A; Mon, 5 Dec 2011 13:39:03 +0000 (UTC) Received: by ggnp1 with SMTP id p1so2958835ggn.13 for ; Mon, 05 Dec 2011 05:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PsC1HzLijqFC/AsuEeYRqz9VshQWzuFRP5iZ/24mSZk=; b=FrIIUoFof4B4gP1b+npxcn63Q9MnbahI280EPao2DoWxUYbuKd6FDNKTqedMuTc3pu SjejrxJ+pOAkxnYZ8Lkfl2v9y8yNsJd4QqhtST10rjm87V/yB+4GmW9jWP6/2K+CPFBb eh/crsP48DdYg2MVjUDxRYHa0vMwuVkuBTW8I= MIME-Version: 1.0 Received: by 10.182.231.38 with SMTP id td6mr340813obc.66.1323090975419; Mon, 05 Dec 2011 05:16:15 -0800 (PST) Sender: pluknet@gmail.com Received: by 10.182.142.101 with HTTP; Mon, 5 Dec 2011 05:16:15 -0800 (PST) In-Reply-To: <20111204222203.GA8898@freebsd.org> References: <20111204222203.GA8898@freebsd.org> Date: Mon, 5 Dec 2011 16:16:15 +0300 X-Google-Sender-Auth: 1KbpfYPYsO9HpUFl_gQ2T5Laoo0 Message-ID: From: Sergey Kandaurov To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 13:39:03 -0000 On 5 December 2011 02:22, Alexander Best wrote: > hi there, > > i was going through the clang warnings from a GENERIC buildkernel and not= iced > the following: > > =3D=3D=3D> drm/mga (all) > /usr/subversion-src/sys/modules/drm/mga/../../../dev/drm/mga_state.c:56:2= : error: invalid conversion specifier 'Z' [-Werror,-Wformat-invalid-specifi= er] > =A0 =A0 =A0 =A0BEGIN_DMA(2); > =A0 =A0 =A0 =A0^~~~~~~~~~~ > @/dev/drm/mga_drv.h:291:35: note: expanded from: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DRM_INFO( " =A0 space=3D0x%x req=3D0x%Zx\n= ", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0^ > @/dev/drm/drmP.h:317:60: note: expanded from: > #define DRM_INFO(fmt, ...) =A0printf("info: [" DRM_NAME "] " fmt , ##__VA= _ARGS__) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ > these lines should cover all warnings: > > otaku% egrep -r "%[0-9]*Zx" /usr/src/sys/dev/drm > dev/drm/mga_drv.h: =A0 =A0 =A0 =A0 =A0 =A0 =A0DRM_INFO( " =A0 space=3D0x%= x req=3D0x%Zx\n", =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ > dev/drm/mga_drv.h: =A0 =A0 =A0 =A0 =A0 =A0 =A0DRM_INFO( " =A0 DMA_WRITE( = 0x%08x ) at 0x%04Zx\n", =A0 =A0 =A0 =A0\ > > ... i couldn't find a reference to an upercase "Z" in the printf(9) man p= age. > i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" mig= ht > come from linux'es libc5 and is the equaivalent to glibc's "z". > > can we adjust those lines, so the clang warnings disappear? Hi, Alexander. Can you build-test with this change? Thanks in advance. Index: sys/dev/drm/mga_drv.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/drm/mga_drv.h (revision 228276) +++ sys/dev/drm/mga_drv.h (working copy) @@ -288,7 +288,7 @@ do { \ if ( MGA_VERBOSE ) { \ DRM_INFO( "BEGIN_DMA( %d )\n", (n) ); \ - DRM_INFO( " space=3D0x%x req=3D0x%Zx\n", = \ + DRM_INFO( " space=3D0x%x req=3D0x%x\n", = \ dev_priv->prim.space, (n) * DMA_BLOCK_SIZE ); \ } \ prim =3D dev_priv->prim.start; \ @@ -338,7 +338,7 @@ #define DMA_WRITE( offset, val ) \ do { \ if ( MGA_VERBOSE ) { \ - DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04Zx\n", \ + DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04x\n", \ (u32)(val), write + (offset) * sizeof(u32) ); \ } \ *(volatile u32 *)(prim + write + (offset) * sizeof(u32)) =3D val; \ --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 14:38:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 2C815106566C; Mon, 5 Dec 2011 14:38:15 +0000 (UTC) Date: Mon, 5 Dec 2011 14:38:15 +0000 From: Alexander Best To: Sergey Kandaurov Message-ID: <20111205143815.GA34379@freebsd.org> References: <20111204222203.GA8898@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:38:15 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon Dec 5 11, Sergey Kandaurov wrote: > On 5 December 2011 02:22, Alexander Best wrote: > > hi there, > > > > i was going through the clang warnings from a GENERIC buildkernel and noticed > > the following: > > > > ===> drm/mga (all) > > /usr/subversion-src/sys/modules/drm/mga/../../../dev/drm/mga_state.c:56:2: error: invalid conversion specifier 'Z' [-Werror,-Wformat-invalid-specifier] > >        BEGIN_DMA(2); > >        ^~~~~~~~~~~ > > @/dev/drm/mga_drv.h:291:35: note: expanded from: > >                DRM_INFO( "   space=0x%x req=0x%Zx\n",                  \ > >                                                ^ > > @/dev/drm/drmP.h:317:60: note: expanded from: > > #define DRM_INFO(fmt, ...)  printf("info: [" DRM_NAME "] " fmt , ##__VA_ARGS__) > >                                                           ^ > > these lines should cover all warnings: > > > > otaku% egrep -r "%[0-9]*Zx" /usr/src/sys/dev/drm > > dev/drm/mga_drv.h:              DRM_INFO( "   space=0x%x req=0x%Zx\n",                  \ > > dev/drm/mga_drv.h:              DRM_INFO( "   DMA_WRITE( 0x%08x ) at 0x%04Zx\n",        \ > > > > ... i couldn't find a reference to an upercase "Z" in the printf(9) man page. > > i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might > > come from linux'es libc5 and is the equaivalent to glibc's "z". > > > > can we adjust those lines, so the clang warnings disappear? > > Hi, Alexander. > > Can you build-test with this change? > Thanks in advance. no that didn't work, but the following patch fixed it for me. cheers. alex > > Index: sys/dev/drm/mga_drv.h > =================================================================== > --- sys/dev/drm/mga_drv.h (revision 228276) > +++ sys/dev/drm/mga_drv.h (working copy) > @@ -288,7 +288,7 @@ > do { \ > if ( MGA_VERBOSE ) { \ > DRM_INFO( "BEGIN_DMA( %d )\n", (n) ); \ > - DRM_INFO( " space=0x%x req=0x%Zx\n", \ > + DRM_INFO( " space=0x%x req=0x%x\n", \ > dev_priv->prim.space, (n) * DMA_BLOCK_SIZE ); \ > } \ > prim = dev_priv->prim.start; \ > @@ -338,7 +338,7 @@ > #define DMA_WRITE( offset, val ) \ > do { \ > if ( MGA_VERBOSE ) { \ > - DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04Zx\n", \ > + DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04x\n", \ > (u32)(val), write + (offset) * sizeof(u32) ); \ > } \ > *(volatile u32 *)(prim + write + (offset) * sizeof(u32)) = val; \ > > -- > wbr, > pluknet --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mga_drv.h.diff" Index: sys/dev/drm/mga_drv.h =================================================================== --- sys/dev/drm/mga_drv.h (revision 228276) +++ sys/dev/drm/mga_drv.h (working copy) @@ -288,7 +288,7 @@ do { \ if ( MGA_VERBOSE ) { \ DRM_INFO( "BEGIN_DMA( %d )\n", (n) ); \ - DRM_INFO( " space=0x%x req=0x%Zx\n", \ + DRM_INFO( " space=0x%x req=0x%lx\n", \ dev_priv->prim.space, (n) * DMA_BLOCK_SIZE ); \ } \ prim = dev_priv->prim.start; \ @@ -338,7 +338,7 @@ #define DMA_WRITE( offset, val ) \ do { \ if ( MGA_VERBOSE ) { \ - DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04Zx\n", \ + DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04lx\n", \ (u32)(val), write + (offset) * sizeof(u32) ); \ } \ *(volatile u32 *)(prim + write + (offset) * sizeof(u32)) = val; \ --tKW2IUtsqtDRztdT-- From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 17:16:57 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A259D106566C for ; Mon, 5 Dec 2011 17:16:57 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 33C938FC0C for ; Mon, 5 Dec 2011 17:16:56 +0000 (UTC) Received: by eekc1 with SMTP id c1so843656eek.13 for ; Mon, 05 Dec 2011 09:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=SFKATan7cO/20tmuyO6Yl0evIJ91GjjCmvYG1FOu6TQ=; b=I4y6S5+7koiaNB2QkWlriNR2aVhp413k43ZeJp/duNipileq9P7Me/2qQXhAObbbAg lifZ7uPC3Ss0QSqSsowH+hC49CK7KQZiF8ZHg0BcI/YoHky9BVF+kRpwUmdsYk4q00V1 ky/mMFaaz5hLikA9yeAtV7i+84jvjgPMsoXkI= Received: by 10.213.27.15 with SMTP id g15mr1151088ebc.111.1323105416119; Mon, 05 Dec 2011 09:16:56 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id c9sm59090484eeb.0.2011.12.05.09.16.53 (version=SSLv3 cipher=OTHER); Mon, 05 Dec 2011 09:16:54 -0800 (PST) Message-ID: <20111205.171654.020.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Mon, 05 Dec 2011 18:16:54 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:16:57 -0000 I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on = it.=0D=0AThen I've installed 'benchmarks/unixbench' port.=0D=0A=0D=0ASo = everything is a default generic binary install ('make.conf' empty - no = CPU optimization flags)=0D=0A=0D=0AAfter running: '# time unixbench', = final score was:=0D=0A 394.2=0D=0ACompleted in 22.8 = min=0D=0A=0D=0A=0D=0AThen I've recompiled everything, from src, world and = kernel, with = 'make.conf':=0D=0A--=0D=0ACPUTYPE?=3Dcore2=0D=0ACFLAGS+=3D-march=3Dnative=0D=0ANO_CPU_CFLAGS=3Dyes=0D=0ACOPTFLAGS+=3D-march=3Dnative=0D=0ANO_CPU_COPTFLAGS=3Dyes=0D=0A--=0D=0A=0D=0AAfter = reboot, I've run: '# time unixbench', final score was:=0D=0A = 313.5=0D=0ACompleted in 26.7 min=0D=0A=0D=0AI'm getting worse result, = with optimized FreeBSD's binaries?!?=0D=0AHow = come?=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 17:19:15 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B3DC1065670 for ; Mon, 5 Dec 2011 17:19:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C440A8FC0A for ; Mon, 5 Dec 2011 17:19:14 +0000 (UTC) Received: by ggnp1 with SMTP id p1so3285015ggn.13 for ; Mon, 05 Dec 2011 09:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=srDUeryq4kK96MWbnLGRIlDFE7BjMA+UslXUK4qLwS4=; b=vpZIGe8FWqfXH+uBdp7lRHrngFgXhzEHfWGZ5hyLv2vc+N9i1iz/QkqqI5hHgSo+LW UGSOHwExJallfgtUdFYcteNG522vPoXWO0kFj2bdaTDYg+ree5PczdvDUchiFHDiNMlL GQX0jj1jL/xjymOL6NpE6f4IKFhot8O7t8a54= MIME-Version: 1.0 Received: by 10.182.40.65 with SMTP id v1mr1927907obk.72.1323105554158; Mon, 05 Dec 2011 09:19:14 -0800 (PST) Received: by 10.182.62.227 with HTTP; Mon, 5 Dec 2011 09:19:14 -0800 (PST) In-Reply-To: <20111205.171654.020.1@DOMY-PC> References: <20111205.171654.020.1@DOMY-PC> Date: Mon, 5 Dec 2011 09:19:14 -0800 Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:19:15 -0000 2011/12/5 : > I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on i= t. > Then I've installed 'benchmarks/unixbench' port. > > So everything is a default generic binary install ('make.conf' empty - no= CPU optimization flags) > > After running: '# time unixbench', final score was: > =A0 =A0394.2 > Completed in 22.8 min > > > Then I've recompiled everything, from src, world and kernel, with 'make.c= onf': > -- > CPUTYPE?=3Dcore2 > CFLAGS+=3D-march=3Dnative > NO_CPU_CFLAGS=3Dyes > COPTFLAGS+=3D-march=3Dnative > NO_CPU_COPTFLAGS=3Dyes > -- > > After reboot, I've run: '# time unixbench', final score was: > =A0 =A0313.5 > Completed in 26.7 min > > I'm getting worse result, with optimized FreeBSD's binaries?!? > How come? Seems like -march=3Dnative is redundant. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 17:27:30 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188FE106566C for ; Mon, 5 Dec 2011 17:27:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB5D68FC0A for ; Mon, 5 Dec 2011 17:27:29 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so6570817vbb.13 for ; Mon, 05 Dec 2011 09:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iPucqHmt/GsDhkCnvUX9Qhtby15CPz+kECG3RzGSDP0=; b=Iv7ue36fvaqqwX6fOKY9gW+kHAP4HoupwneaZKBsH8AW3mO93+5ZeDpe04q2IE2XRj n5m7ftidtpwrlk7S9bcqyZKWXRTHWKK5RQ3++pHlJCcL297Fp/eOa9qCp/kNHZqeFcN5 FU88xec5qn629V0JoDVx9DhBBft/1UQqDrJnQ= MIME-Version: 1.0 Received: by 10.52.35.147 with SMTP id h19mr5396899vdj.38.1323106049045; Mon, 05 Dec 2011 09:27:29 -0800 (PST) Received: by 10.220.231.10 with HTTP; Mon, 5 Dec 2011 09:27:29 -0800 (PST) In-Reply-To: <20111205.171654.020.1@DOMY-PC> References: <20111205.171654.020.1@DOMY-PC> Date: Mon, 5 Dec 2011 09:27:29 -0800 Message-ID: From: Freddie Cash To: rank1seeker@gmail.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:27:30 -0000 2011/12/5 > I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on it. > Then I've installed 'benchmarks/unixbench' port. > > So everything is a default generic binary install ('make.conf' empty - no > CPU optimization flags) > > After running: '# time unixbench', final score was: > 394.2 > Completed in 22.8 min > > > Then I've recompiled everything, from src, world and kernel, with > 'make.conf': > -- > CPUTYPE?=core2 > CFLAGS+=-march=native > NO_CPU_CFLAGS=yes > COPTFLAGS+=-march=native > NO_CPU_COPTFLAGS=yes > And, how does it do if you remove everything except the CPUTYPE line? Most of the rest if unnecessary. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 17:31:50 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33036106566B for ; Mon, 5 Dec 2011 17:31:50 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E40228FC08 for ; Mon, 5 Dec 2011 17:31:49 +0000 (UTC) Received: by ywp17 with SMTP id 17so6420816ywp.13 for ; Mon, 05 Dec 2011 09:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=f43O917vKrvjk/B/VvoEptO0RrLqhRaw/cSvA7WiG3Q=; b=SMXEs5ZHM18yC1fBYGVncJLBud2e+AM1MoQSOQaU+FidJf2gtWwOstYKCI+Opb+SUn +A4dixZR+W5G/BgjyCHVgV/o9MGZpa2Vr9E8IuV00Z0B4BsibPs2ECCQSXnBPGOs+csu vq1ETP0nRkqvBRBBsaMoTSz0rZ4JgwRfAAwt4= MIME-Version: 1.0 Received: by 10.50.40.198 with SMTP id z6mr11056221igk.39.1323106308859; Mon, 05 Dec 2011 09:31:48 -0800 (PST) Sender: utisoft@gmail.com Received: by 10.231.12.139 with HTTP; Mon, 5 Dec 2011 09:31:48 -0800 (PST) Received: by 10.231.12.139 with HTTP; Mon, 5 Dec 2011 09:31:48 -0800 (PST) In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> Date: Mon, 5 Dec 2011 17:31:48 +0000 X-Google-Sender-Auth: -Hytacs3SDgdH7d3sZYuGdS58F4 Message-ID: From: Chris Rees To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:31:50 -0000 On 5 Dec 2011 17:27, "Freddie Cash" wrote: > > 2011/12/5 > > > I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on it. > > Then I've installed 'benchmarks/unixbench' port. > > > > So everything is a default generic binary install ('make.conf' empty - no > > CPU optimization flags) > > > > After running: '# time unixbench', final score was: > > 394.2 > > Completed in 22.8 min > > > > > > Then I've recompiled everything, from src, world and kernel, with > > 'make.conf': > > -- > > CPUTYPE?=core2 > > CFLAGS+=-march=native > > NO_CPU_CFLAGS=yes > > COPTFLAGS+=-march=native > > NO_CPU_COPTFLAGS=yes > > > > And, how does it do if you remove everything except the CPUTYPE line? Most > of the rest if unnecessary. > Also, you should set these in src.conf. Sticking them in make.conf is going to annoy people when you ask why your ports are breaking ;) Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 18:05:05 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FBFC106564A for ; Mon, 5 Dec 2011 18:05:05 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C79D38FC15 for ; Mon, 5 Dec 2011 18:05:04 +0000 (UTC) Received: by qcse13 with SMTP id e13so2354619qcs.13 for ; Mon, 05 Dec 2011 10:05:04 -0800 (PST) Received: by 10.229.95.205 with SMTP id e13mr30303qcn.2.1323106461490; Mon, 05 Dec 2011 09:34:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.216.15 with HTTP; Mon, 5 Dec 2011 09:33:50 -0800 (PST) In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> From: Maxim Khitrov Date: Mon, 5 Dec 2011 12:33:50 -0500 Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:05:05 -0000 On Mon, Dec 5, 2011 at 12:19 PM, Garrett Cooper wrote: > 2011/12/5 =C2=A0: >> I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on = it. >> Then I've installed 'benchmarks/unixbench' port. >> >> So everything is a default generic binary install ('make.conf' empty - n= o CPU optimization flags) >> >> After running: '# time unixbench', final score was: >> =C2=A0 =C2=A0394.2 >> Completed in 22.8 min >> >> >> Then I've recompiled everything, from src, world and kernel, with 'make.= conf': >> -- >> CPUTYPE?=3Dcore2 >> CFLAGS+=3D-march=3Dnative >> NO_CPU_CFLAGS=3Dyes >> COPTFLAGS+=3D-march=3Dnative >> NO_CPU_COPTFLAGS=3Dyes >> -- >> >> After reboot, I've run: '# time unixbench', final score was: >> =C2=A0 =C2=A0313.5 >> Completed in 26.7 min >> >> I'm getting worse result, with optimized FreeBSD's binaries?!? >> How come? > > Seems like -march=3Dnative is redundant. > -Garrett Not only is it redundant, but it might be undoing to effects of CPUTYPE. Run the following command, it tells you what gcc ends up optimizing for when you use -march=3Dnative: /bin/sh -c "gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=3D//'" On most of my machines, native is the same as generic. Rerun your test with just 'CPUTYPE?=3Dcore2' line in make.conf and see what the results are. Usually, there is no need to specify any other options. Also, in 8.2 'core2' seems to be an alias for 'prescott'. You have to use FreeBSD 9.0 for core2 to be available in gcc. - Max From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 18:12:30 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3E5B106566B for ; Mon, 5 Dec 2011 18:12:30 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 95F2F8FC0C for ; Mon, 5 Dec 2011 18:12:30 +0000 (UTC) Received: by ggnp1 with SMTP id p1so3362709ggn.13 for ; Mon, 05 Dec 2011 10:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MEJdZqToYfOUHeCj7LBBaxQRKi0Cnv+p9idai+aGC1c=; b=pvWbFzMU08zxbr28XwMe19N5rGbn2rhURAWEcy/tWOzcl17DzQ7RlXjeB2RaUo0vk0 GrLwgza/PE7Ta3al9iADwi3OEcn197s16gUcplak3jTImMb5wkAgo6GuGZDCeSKtKYt9 ryK6OOT60bcwaoqGspN09GMjasTl/y0dnIEtQ= MIME-Version: 1.0 Received: by 10.182.180.5 with SMTP id dk5mr1939702obc.7.1323107032057; Mon, 05 Dec 2011 09:43:52 -0800 (PST) Received: by 10.182.47.38 with HTTP; Mon, 5 Dec 2011 09:43:52 -0800 (PST) In-Reply-To: <20111205.171654.020.1@DOMY-PC> References: <20111205.171654.020.1@DOMY-PC> Date: Mon, 5 Dec 2011 18:43:52 +0100 Message-ID: From: Oliver Pinter To: rank1seeker@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:12:30 -0000 On 12/5/11, rank1seeker@gmail.com wrote: > I've took machine and installed binary FreeBSD(amd64 8.2-p4 GENERIC) on i= t. > Then I've installed 'benchmarks/unixbench' port. > > So everything is a default generic binary install ('make.conf' empty - no > CPU optimization flags) > > After running: '# time unixbench', final score was: > 394.2 > Completed in 22.8 min > > > Then I've recompiled everything, from src, world and kernel, with > 'make.conf': > -- > CPUTYPE?=3Dcore2 > CFLAGS+=3D-march=3Dnative > NO_CPU_CFLAGS=3Dyes > COPTFLAGS+=3D-march=3Dnative > NO_CPU_COPTFLAGS=3Dyes > -- > > After reboot, I've run: '# time unixbench', final score was: > 313.5 > Completed in 26.7 min > > I'm getting worse result, with optimized FreeBSD's binaries?!? > How come? What is the test environment? All tests running after a reboot? (if not, then do...) Run all test in single user, when freebsd reboots, after the system become up, than we have a running bgfsck (fixme). And run the tests in multiple time, example with make.conf setting 5X and without make.conf setting 5X. > > > Domagoj Smol=C4=8Di=C4=87 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 21:55:20 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F414106566B; Mon, 5 Dec 2011 21:55:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 489408FC16; Mon, 5 Dec 2011 21:55:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA19458; Mon, 05 Dec 2011 23:55:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RXgVI-000LJn-N6; Mon, 05 Dec 2011 23:55:16 +0200 Message-ID: <4EDD3DC2.1020405@FreeBSD.org> Date: Mon, 05 Dec 2011 23:55:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111108 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111204222203.GA8898@freebsd.org> <20111205143815.GA34379@freebsd.org> In-Reply-To: <20111205143815.GA34379@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Sergey Kandaurov Subject: Re: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:55:20 -0000 on 05/12/2011 16:38 Alexander Best said the following: > On Mon Dec 5 11, Sergey Kandaurov wrote: >> On 5 December 2011 02:22, Alexander Best wrote: >>> hi there, >>> >>> i was going through the clang warnings from a GENERIC buildkernel and noticed >>> the following: >>> >>> ===> drm/mga (all) >>> /usr/subversion-src/sys/modules/drm/mga/../../../dev/drm/mga_state.c:56:2: error: invalid conversion specifier 'Z' [-Werror,-Wformat-invalid-specifier] >>> BEGIN_DMA(2); >>> ^~~~~~~~~~~ >>> @/dev/drm/mga_drv.h:291:35: note: expanded from: >>> DRM_INFO( " space=0x%x req=0x%Zx\n", \ >>> ^ >>> @/dev/drm/drmP.h:317:60: note: expanded from: >>> #define DRM_INFO(fmt, ...) printf("info: [" DRM_NAME "] " fmt , ##__VA_ARGS__) >>> ^ >>> these lines should cover all warnings: >>> >>> otaku% egrep -r "%[0-9]*Zx" /usr/src/sys/dev/drm >>> dev/drm/mga_drv.h: DRM_INFO( " space=0x%x req=0x%Zx\n", \ >>> dev/drm/mga_drv.h: DRM_INFO( " DMA_WRITE( 0x%08x ) at 0x%04Zx\n", \ >>> >>> ... i couldn't find a reference to an upercase "Z" in the printf(9) man page. >>> i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might >>> come from linux'es libc5 and is the equaivalent to glibc's "z". >>> >>> can we adjust those lines, so the clang warnings disappear? >> >> Hi, Alexander. >> >> Can you build-test with this change? >> Thanks in advance. > > no that didn't work, but the following patch fixed it for me. What about Z => z ? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 21:23:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 498301065670 for ; Mon, 5 Dec 2011 21:23:48 +0000 (UTC) (envelope-from bsd.mharv@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F3F88FC0A for ; Mon, 5 Dec 2011 21:23:47 +0000 (UTC) Received: by yenm2 with SMTP id m2so2921920yen.13 for ; Mon, 05 Dec 2011 13:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TyOS5D/UR151IFFn3aRrc1YLeTJG23P+3S154SC9xQA=; b=lDLMyMTALZZ/rVKuoKiYoAq8l896PxzLOqQVIpxj46/cSVPy5Lvg0ajec0uGhjeT1N 7+I7vc6NnJ4jI6jc7yN3bHlUz+dTU9AeAwAKLDfgoBxm7dgSO6Y54dELTZBEdaNVBU94 C3c1CaDtgGei6147JdIgiIo8cJZ9rW6ZVQyuU= MIME-Version: 1.0 Received: by 10.236.85.174 with SMTP id u34mr14576629yhe.28.1323118455626; Mon, 05 Dec 2011 12:54:15 -0800 (PST) Received: by 10.147.125.10 with HTTP; Mon, 5 Dec 2011 12:54:15 -0800 (PST) Date: Mon, 5 Dec 2011 12:54:15 -0800 Message-ID: From: some body To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 05 Dec 2011 22:55:28 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: boot0.S empty #ifdef X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:23:48 -0000 I sent this to freebsd-drives too but I think that might not be the right list for it so here it is: I am starting to learn how the kernel works and have started by going through the boot loader and I've noticed that between lines 21-32 in boot0.S there are some empty #ifdef statements. I was wondering a) where are these paramaters defined and if they are defined, what difference does it make since it looks like it doesn't change anything since they're empty? #ifdef SIO #endif #ifdef CHECK_DRIVE #endif #ifdef ONLY_F_KEYS #endif From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 5 23:34:40 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA35106566C for ; Mon, 5 Dec 2011 23:34:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 96C9F8FC14 for ; Mon, 5 Dec 2011 23:34:39 +0000 (UTC) Received: by faak28 with SMTP id k28so5255655faa.13 for ; Mon, 05 Dec 2011 15:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v0JzMiYlPOW6eGvnR2n1SJ+Kaj8l6+Bsl/3IsVLa1Go=; b=eU4s8dREvj+JKat2SpeKtm1QTp/wA3dD3vmPw5bSmOryzgxIKUPYNVB6XCypPF3e9D UHSSIRhyPh+dTsT82/GMPAIL9WFhv8oYH6mpLGWA9RDAFDw4pRgPRlo3/Wsg/g9pFAAZ Fj++3l0dK0lhwpH8Roim5otJ953m/YNLNGsA0= Received: by 10.227.209.85 with SMTP id gf21mr217550wbb.5.1323128078376; Mon, 05 Dec 2011 15:34:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.70.196 with HTTP; Mon, 5 Dec 2011 15:34:07 -0800 (PST) In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> From: Eitan Adler Date: Mon, 5 Dec 2011 18:34:07 -0500 Message-ID: To: Oliver Pinter Content-Type: text/plain; charset=UTF-8 Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 23:34:40 -0000 On Mon, Dec 5, 2011 at 12:43 PM, Oliver Pinter wrote: >... benchmarks ... http://zedshaw.com/essays/programmer_stats.html -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 11:07:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B98F71065670 for ; Tue, 6 Dec 2011 11:07:54 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 47FEC8FC0A for ; Tue, 6 Dec 2011 11:07:53 +0000 (UTC) Received: by eaai12 with SMTP id i12so6926186eaa.13 for ; Tue, 06 Dec 2011 03:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=GoEzi2ESPtrrSBGAb5Du1QNvp3/VgrcFgy3LIL+tQpY=; b=ZVSOYR5esNRwjbug3iiAWV9CCmTLGCgJiQKTTWMiIey2O0aKXowOxZkkhsclYLsVjo FgdpzWN3AZBK1ztYigOwqR9fXvMlPJwQ76qM4shfxXxBdguqeeeRphWcppdY7RrKMxvR wxsyb9xf42owDk85D+d8yWi6t/uBwS6QiFWuo= Received: by 10.213.13.136 with SMTP id c8mr2280115eba.15.1323168244639; Tue, 06 Dec 2011 02:44:04 -0800 (PST) Received: from ernst.jennejohn.org (p578E3F12.dip.t-dialin.net. [87.142.63.18]) by mx.google.com with ESMTPS id 49sm69730172eec.1.2011.12.06.02.44.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 02:44:03 -0800 (PST) Date: Tue, 6 Dec 2011 11:44:00 +0100 From: Gary Jennejohn To: some body Message-ID: <20111206114400.6dbea313@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: boot0.S empty #ifdef X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:07:54 -0000 On Mon, 5 Dec 2011 12:54:15 -0800 some body wrote: > I sent this to freebsd-drives too but I think that might not be the right > list for it so here it is: I am starting to learn how the kernel works and > have started by going through the boot loader and I've noticed that between > lines 21-32 in boot0.S there are some empty #ifdef statements. I was > wondering a) where are these paramaters defined and if they are defined, > what difference does it make since it looks like it doesn't change anything > since they're empty? > > > #ifdef SIO > #endif > > #ifdef CHECK_DRIVE > #endif > > #ifdef ONLY_F_KEYS > #endif > These seem to be there to act as reminders for command line options which can be used to build boot0. They're also documented in Makefile. These are actually used later in the code. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 17:03:48 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D5A21065677 for ; Tue, 6 Dec 2011 17:03:48 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 979308FC13 for ; Tue, 6 Dec 2011 17:03:47 +0000 (UTC) Received: by eekc1 with SMTP id c1so2180225eek.13 for ; Tue, 06 Dec 2011 09:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=55rS3Pfx1fjN3qcNj+0QJKLrp1RxbzEuJTYztL686DE=; b=UCgliTHRARY3Hn72R0jspBKDLt0P6pGl+uERdNPoRmyA7SWDlyJJtDa8IbcDHErRsy dwhMji6oQvUezina5zIA5DkbJBklsU0RdzgJMT3LQp15ejiObgSR4AiV4gjHyxTbjp4z soEwi7xjrpkMQxO7kaOhBQw7aMDTaG9au8Ucg= Received: by 10.14.12.147 with SMTP id 19mr1780307eez.151.1323191026310; Tue, 06 Dec 2011 09:03:46 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id x12sm73075843eef.9.2011.12.06.09.03.42 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 09:03:44 -0800 (PST) Message-ID: <20111206.170342.731.2@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Tue, 06 Dec 2011 18:03:42 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:03:48 -0000 # /bin/sh -c "gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1 | = grep mtune | sed -e 's/.*mtune=3D//'"=0D=0Ageneric=0D=0A=0D=0AFor target = machine, it returned 'generic'=0D=0A=0D=0ANow only with CPUTYPE in = 'make.conf':=0D=0A--=0D=0ACPUTYPE?=3Dcore2=0D=0A--=0D=0A=0D=0A> Also, you = should set these in src.conf. Sticking them in make.conf is=0D=0A> going = to annoy people when you ask why your ports are breaking ;)=0D=0A> = =0D=0A> Chris=0D=0A=0D=0AI want my ports, to also be optimized for target = CPU, not just base.=0D=0ANone of my ports got broken = yet.=0D=0A=0D=0ARebuilded can ...=0D=0A=0D=0ATests are started AFTER a = reboot!=0D=0AThere is no bgfsck, as per = rc.conf:=0D=0A--=0D=0Abackground_fsck=3DNO=0D=0Afsck_y_enable=3DYES=0D=0Afsck_y_flags=3D-C=0D=0A--=0D=0A=0D=0ASame = multiuser enviroment=0D=0ATest done once.=0D=0A=0D=0AAfter running: '# = time unixbench', final score was:=0D=0A=A0 =A0395.4=0D=0ACompleted in = 22.8 min=0D=0A=0D=0ATime is SAME as with generic binaries, but score is = just a 1.2 higher, which is too small to be relevant.=0D=0AWhat do you = think about this?=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 17:24:11 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E0521065670 for ; Tue, 6 Dec 2011 17:24:11 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 169B58FC17 for ; Tue, 6 Dec 2011 17:24:10 +0000 (UTC) Received: by iafi7 with SMTP id i7so7487273iaf.13 for ; Tue, 06 Dec 2011 09:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8nn9HXYjEzZos2dSATbWoSWLjRaicGNZNO2gG2x51ck=; b=MaFi/Opd0cALqrHGI56n0d4/GOPw13BajphIKi9P4z/LSihWXY1KaKyQ1cPROIHDu1 wln7dI+OcOfaGP77gssvux4Ucil5r7O472R7VsUZ4Yai0w8q26kuxHUbT0sgoVrJPyzu bPMgyV8CxbIoZ+pmzI+oAFVVwvb9H7wu7X16c= MIME-Version: 1.0 Received: by 10.231.46.66 with SMTP id i2mr3586815ibf.0.1323192250422; Tue, 06 Dec 2011 09:24:10 -0800 (PST) Received: by 10.231.167.83 with HTTP; Tue, 6 Dec 2011 09:24:10 -0800 (PST) Received: by 10.231.167.83 with HTTP; Tue, 6 Dec 2011 09:24:10 -0800 (PST) In-Reply-To: <20111206.170342.731.2@DOMY-PC> References: <20111205.171654.020.1@DOMY-PC> <20111206.170342.731.2@DOMY-PC> Date: Tue, 6 Dec 2011 17:24:10 +0000 Message-ID: From: Chris Rees To: rank1seeker@gmail.com X-Mailman-Approved-At: Tue, 06 Dec 2011 17:32:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 17:24:11 -0000 On 6 Dec 2011 17:04, wrote: > > # /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'" > generic > > For target machine, it returned 'generic' > > Now only with CPUTYPE in 'make.conf': > -- > CPUTYPE?=core2 > -- > > > Also, you should set these in src.conf. Sticking them in make.conf is > > going to annoy people when you ask why your ports are breaking ;) > > > > Chris > > I want my ports, to also be optimized for target CPU, not just base. > None of my ports got broken yet. I was referring to the other stuff, but CPUTYPE is fine, yes. > Rebuilded can ... > > Tests are started AFTER a reboot! > There is no bgfsck, as per rc.conf: > -- > background_fsck=NO > fsck_y_enable=YES > fsck_y_flags=-C > -- > > Same multiuser enviroment > Test done once. > > After running: '# time unixbench', final score was: > 395.4 > Completed in 22.8 min > > Time is SAME as with generic binaries, but score is just a 1.2 higher, which is too small to be relevant. > What do you think about this? > I think this is why most people don't bother with setting CPUTYPE ;) Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 18:35:28 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14FBE106566C for ; Tue, 6 Dec 2011 18:35:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93E618FC0A for ; Tue, 6 Dec 2011 18:35:27 +0000 (UTC) Received: by lagv3 with SMTP id v3so1364330lag.13 for ; Tue, 06 Dec 2011 10:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iTcilb+v9XFcpl71/NUecP3rtdVO1C0jB2NuYkyDdN4=; b=jqoIkLmDpx14RwbjwEs7WPMKOsLszxUaGT6xzbHNHlug9vrL3hNFH0H0prI7Nww5xy aHXWJuv7thuxltStQX6TI3LwWvX9fA72RD1Aw+SBEoOxsqi9/Fz9qAYjTAh5f8qlfdJs fWb79UbV80+UTcRN5/HUdmoMCGyZxD9gZrtK8= Received: by 10.152.105.211 with SMTP id go19mr9725673lab.31.1323196526187; Tue, 06 Dec 2011 10:35:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.36.165 with HTTP; Tue, 6 Dec 2011 10:34:55 -0800 (PST) In-Reply-To: <20111206.170342.731.2@DOMY-PC> References: <20111205.171654.020.1@DOMY-PC> <20111206.170342.731.2@DOMY-PC> From: Eitan Adler Date: Tue, 6 Dec 2011 13:34:55 -0500 Message-ID: To: rank1seeker@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:35:28 -0000 2011/12/6 : > # /bin/sh -c "gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'" > Test done once. > What do you think about this? As usual, it very well *may* be true, but please use ministat(1) to confirm. This requires more than one test. I'm not trying to be difficult - but statistics and benchmarking is non-trivial. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 18:42:40 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56B2B1065677 for ; Tue, 6 Dec 2011 18:42:40 +0000 (UTC) (envelope-from max@mxcrypt.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1819E8FC15 for ; Tue, 6 Dec 2011 18:42:39 +0000 (UTC) Received: by qcse13 with SMTP id e13so3597404qcs.13 for ; Tue, 06 Dec 2011 10:42:39 -0800 (PST) Received: by 10.229.63.156 with SMTP id b28mr1916005qci.40.1323196959271; Tue, 06 Dec 2011 10:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.216.15 with HTTP; Tue, 6 Dec 2011 10:42:08 -0800 (PST) In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> <20111206.170342.731.2@DOMY-PC> From: Maxim Khitrov Date: Tue, 6 Dec 2011 13:42:08 -0500 Message-ID: To: Eitan Adler Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:42:40 -0000 On Tue, Dec 6, 2011 at 1:34 PM, Eitan Adler wrote: > 2011/12/6 =C2=A0: >> # /bin/sh -c "gcc -v -x c -E -mtune=3Dnative /dev/null -o /dev/null 2>&1= | grep mtune | sed -e 's/.*mtune=3D//'" >> Test done once. > >> What do you think about this? > > As usual, it very well *may* be true, but please use ministat(1) to > confirm. This requires more than one test. I'm not trying to be > difficult - but statistics and benchmarking is non-trivial. A few other good suggestions: http://wiki.freebsd.org/BenchmarkAdvice - Max From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 22:08:47 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B95E106564A; Tue, 6 Dec 2011 22:08:47 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 0B71F8FC1C; Tue, 6 Dec 2011 22:08:46 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pB6LsZgd014602; Tue, 6 Dec 2011 16:54:35 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pB6LsZ6C014601; Tue, 6 Dec 2011 16:54:35 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 6 Dec 2011 16:54:35 -0500 From: David Schultz To: Alexander Best Message-ID: <20111206215435.GA14529@zim.MIT.EDU> Mail-Followup-To: Alexander Best , freebsd-hackers@freebsd.org References: <20111204222203.GA8898@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111204222203.GA8898@freebsd.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 22:08:47 -0000 On Sun, Dec 04, 2011, Alexander Best wrote: > ... i couldn't find a reference to an upercase "Z" in the printf(9) man page. > i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might > come from linux'es libc5 and is the equaivalent to glibc's "z". > > can we adjust those lines, so the clang warnings disappear? Yes, 'Z' is an alias for 'z' that is deprecated in glibc and unsupported in FreeBSD, so changing the case should fix it. From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 6 22:48:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7A8441065672; Tue, 6 Dec 2011 22:48:00 +0000 (UTC) Date: Tue, 6 Dec 2011 22:48:00 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111206224800.GA20393@freebsd.org> References: <20111204222203.GA8898@freebsd.org> <20111206215435.GA14529@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111206215435.GA14529@zim.MIT.EDU> Subject: Re: strange printf(9) format specifier ("Z") in dev/drm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 22:48:00 -0000 On Tue Dec 6 11, David Schultz wrote: > On Sun, Dec 04, 2011, Alexander Best wrote: > > ... i couldn't find a reference to an upercase "Z" in the printf(9) man page. > > i talked to dinoex on #freebsd-clang (EFNet) and he said that the "Z" might > > come from linux'es libc5 and is the equaivalent to glibc's "z". > > > > can we adjust those lines, so the clang warnings disappear? > > Yes, 'Z' is an alias for 'z' that is deprecated in glibc and > unsupported in FreeBSD, so changing the case should fix it. i guess turning the "Z"'s into "z"'s would be the best procedure then. cheers. alex From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 01:01:13 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C910106564A for ; Wed, 7 Dec 2011 01:01:13 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 443228FC18 for ; Wed, 7 Dec 2011 01:01:13 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id DC5105C24 for ; Wed, 7 Dec 2011 10:55:34 +1000 (EST) Message-ID: <4EDEB600.9000102@herveybayaustralia.com.au> Date: Wed, 07 Dec 2011 10:40:32 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 01:01:13 -0000 I'm trying to build some newer versions of ffserver. But I keep getting asm build errors when I get to libavcodec/vp*. Error: `(%esi,%eax)' is not a valid 64 bit base/index expression If I set it to build static it fails at h264. "Error: `-1(%edi)' is not a valid 64 bit base/index expression" Googling hasn't proved helpful in finding an answer. I've tried setting some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. Any ideas how to fix this? Cheers From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 10:36:38 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C441065677 for ; Wed, 7 Dec 2011 10:36:38 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2A058FC13 for ; Wed, 7 Dec 2011 10:36:38 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so523248vbb.13 for ; Wed, 07 Dec 2011 02:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/ErVyoR/Y1bZXG8uL+oQpi9tG8F+M6xSR31bfTzl2MY=; b=MOgU5O8qlqc8FZl2b4L9eHxipEAbePeOTuSVzYdhwaEvPP/P7HD7w1Eyf+m6lets/x u0gNHgJBDyT1XL7pinFqtfJKqqB6hL18eLLkzRnDQzpQVAbcftVQUKQrkGacTH3uNQ5y K27GvcvJ3MNjCbypdeLW1gX0LH1PxpSFiei0k= MIME-Version: 1.0 Received: by 10.52.186.225 with SMTP id fn1mr10263831vdc.32.1323254197719; Wed, 07 Dec 2011 02:36:37 -0800 (PST) Received: by 10.52.172.240 with HTTP; Wed, 7 Dec 2011 02:36:37 -0800 (PST) In-Reply-To: <4EDEB600.9000102@herveybayaustralia.com.au> References: <4EDEB600.9000102@herveybayaustralia.com.au> Date: Wed, 7 Dec 2011 10:36:37 +0000 Message-ID: From: Tom Evans To: Da Rock Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 10:36:39 -0000 On Wed, Dec 7, 2011 at 12:40 AM, Da Rock wrote: > I'm trying to build some newer versions of ffserver. But I keep getting a= sm > build errors when I get to libavcodec/vp*. > > Error: `(%esi,%eax)' is not a valid 64 bit base/index expression > > If I set it to build static it fails at h264. > > "Error: `-1(%edi)' =C2=A0is not a valid 64 bit base/index expression" > > Googling hasn't proved helpful in finding an answer. I've tried setting s= ome > configure options: arch=3Damd64/x86_64, disabling cmov/fast_cmov, ebx, et= c. > > Any ideas how to fix this? > > Cheers Yes, you need to use newer binutils from ports. It also helps with ffmpeg/mplayer to use a newer gcc from ports as well (I use gcc46), but the main thing is installing binutils and configuring with --as=3D/usr/local/bin/as. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 11:17:20 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1189106564A for ; Wed, 7 Dec 2011 11:17:20 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 92C878FC14 for ; Wed, 7 Dec 2011 11:17:20 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id C0F935C24 for ; Wed, 7 Dec 2011 21:14:18 +1000 (EST) Message-ID: <4EDF4703.1050705@herveybayaustralia.com.au> Date: Wed, 07 Dec 2011 20:59:15 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 11:17:21 -0000 On 12/07/11 20:36, Tom Evans wrote: > On Wed, Dec 7, 2011 at 12:40 AM, Da Rock > wrote: >> I'm trying to build some newer versions of ffserver. But I keep getting asm >> build errors when I get to libavcodec/vp*. >> >> Error: `(%esi,%eax)' is not a valid 64 bit base/index expression >> >> If I set it to build static it fails at h264. >> >> "Error: `-1(%edi)' is not a valid 64 bit base/index expression" >> >> Googling hasn't proved helpful in finding an answer. I've tried setting some >> configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, ebx, etc. >> >> Any ideas how to fix this? >> >> Cheers > Yes, you need to use newer binutils from ports. It also helps with > ffmpeg/mplayer to use a newer gcc from ports as well (I use gcc46), > but the main thing is installing binutils and configuring with > --as=/usr/local/bin/as. > > Cool! Thanks for that. I got a manual to read by the looks of it anyway, but can anyone give me the inside gos on the why it does what it does? (Or something like that.. :) ) Cheers From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 11:50:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54A22106564A for ; Wed, 7 Dec 2011 11:50:13 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 048D48FC15 for ; Wed, 7 Dec 2011 11:50:12 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 20BEA5C24; Wed, 7 Dec 2011 22:02:34 +1000 (EST) Message-ID: <4EDF5253.5060201@herveybayaustralia.com.au> Date: Wed, 07 Dec 2011 21:47:31 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tom Evans References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 11:50:13 -0000 On 12/07/11 21:29, Tom Evans wrote: > On Wed, Dec 7, 2011 at 10:59 AM, Da Rock > wrote: >> Cool! Thanks for that. >> >> I got a manual to read by the looks of it anyway, but can anyone give me the >> inside gos on the why it does what it does? (Or something like that.. :) ) >> >> > This email explains it: > > http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-July/083051.html > I really hate sounding like an idiot, but if I don't ask I'll never know: The assembler in base is not up-to-date with the latest instruction sets for the cpu, and is causing an error because its telling the cpu to do something it doesn't understand and is going WTF! So the port binutils provides the latest instruction sets for the latest cpus. And ffmpeg and friends use the latest cpu abilities to run as fast as they do? Right or way off? Otherwise I'd have problems building anything, wouldn't I? From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 12:00:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57092106567C for ; Wed, 7 Dec 2011 12:00:35 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0AADE8FC12 for ; Wed, 7 Dec 2011 12:00:34 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so609392vbb.13 for ; Wed, 07 Dec 2011 04:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C6azm69bSVY4H4fcPpHThBnNss5k0FESuDHfKHvN1Mc=; b=tzoIzLhcnrbYiDx6nv5noPfldZt52niHwOoFxMf31gwHRXKecvbEcErsZEV9e94Zmj CCzdeDOkke63E1LC6BqnTprdNWw7Uv0yuHy+/+uwXEGYRXJV25EjvBy8BJAxhiYKdYRV otSk10p/m3+J1xpJ7fcDSdIn1lSFo4EcuRBXc= MIME-Version: 1.0 Received: by 10.52.117.65 with SMTP id kc1mr10353869vdb.66.1323257384782; Wed, 07 Dec 2011 03:29:44 -0800 (PST) Received: by 10.52.172.240 with HTTP; Wed, 7 Dec 2011 03:29:44 -0800 (PST) In-Reply-To: <4EDF4703.1050705@herveybayaustralia.com.au> References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> Date: Wed, 7 Dec 2011 11:29:44 +0000 Message-ID: From: Tom Evans To: Da Rock Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 12:00:35 -0000 On Wed, Dec 7, 2011 at 10:59 AM, Da Rock wrote: > Cool! Thanks for that. > > I got a manual to read by the looks of it anyway, but can anyone give me the > inside gos on the why it does what it does? (Or something like that.. :) ) > > This email explains it: http://lists.mplayerhq.hu/pipermail/mplayer-users/2011-July/083051.html Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 12:17:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA72B1065675 for ; Wed, 7 Dec 2011 12:17:58 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 722788FC0A for ; Wed, 7 Dec 2011 12:17:58 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so628610vbb.13 for ; Wed, 07 Dec 2011 04:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yo+Ml7vRXERVuE5fVExauASZtOkYkP1FBqXGmQzohhI=; b=db5GlfQseNs1L2T9ytmf+dyZlPT8sOLnXo/iqijEXRbJYEYQ8zkrc6P7ALLsri/dGK beeYefoEJarl/0Ycp0mn29vukeftdWvJrs14quBvPJdlMRTDmb/IfEw4Y7jLRvHktBb6 bMFIX4ehnZ4eNJpUbP5qoho10AbHGIS83nw2o= MIME-Version: 1.0 Received: by 10.52.186.225 with SMTP id fn1mr10475785vdc.32.1323260277591; Wed, 07 Dec 2011 04:17:57 -0800 (PST) Received: by 10.52.172.240 with HTTP; Wed, 7 Dec 2011 04:17:57 -0800 (PST) In-Reply-To: <4EDF5253.5060201@herveybayaustralia.com.au> References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> Date: Wed, 7 Dec 2011 12:17:57 +0000 Message-ID: From: Tom Evans To: Da Rock Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 12:17:58 -0000 On Wed, Dec 7, 2011 at 11:47 AM, Da Rock wrote: > I really hate sounding like an idiot, but if I don't ask I'll never know: > The assembler in base is not up-to-date with the latest instruction sets for > the cpu, and is causing an error because its telling the cpu to do something > it doesn't understand and is going WTF! So the port binutils provides the > latest instruction sets for the latest cpus. And ffmpeg and friends use the > latest cpu abilities to run as fast as they do? Right or way off? Otherwise > I'd have problems building anything, wouldn't I? The way I understand it is that they use compiler/assembler features that did not exist in the version of binutils that is in base. That might be related to CPU features - I know you need binutils from ports to use SSE3 features, for example - but whether that is what happens here, or whether it is due to ffmpeg using newer features would have to be answered by someone who understands what is going on! Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 13:52:43 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9DBB106566B for ; Wed, 7 Dec 2011 13:52:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB3A8FC18 for ; Wed, 7 Dec 2011 13:52:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:8945:f03a:980c:c72] (unknown [IPv6:2001:7b8:3a7:0:8945:f03a:980c:c72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 837325C37; Wed, 7 Dec 2011 14:52:42 +0100 (CET) Message-ID: <4EDF6FAC.8000002@FreeBSD.org> Date: Wed, 07 Dec 2011 14:52:44 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111130 Thunderbird/9.0 MIME-Version: 1.0 To: Da Rock References: <4EDEB600.9000102@herveybayaustralia.com.au> In-Reply-To: <4EDEB600.9000102@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 13:52:43 -0000 On 2011-12-07 01:40, Da Rock wrote: > I'm trying to build some newer versions of ffserver. But I keep getting > asm build errors when I get to libavcodec/vp*. > > Error: `(%esi,%eax)' is not a valid 64 bit base/index expression > > If I set it to build static it fails at h264. > > "Error: `-1(%edi)' is not a valid 64 bit base/index expression" > > Googling hasn't proved helpful in finding an answer. I've tried setting > some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, > ebx, etc. > > Any ideas how to fix this? At first glance, I'd say you are compiling it with a 32-bit compiler or assembler. In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, and it compiles just fine with base gcc. What are the exact commands you are running? From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 13:56:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFD341065675 for ; Wed, 7 Dec 2011 13:56:25 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8CDD88FC15 for ; Wed, 7 Dec 2011 13:56:25 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 8CA845C24 for ; Thu, 8 Dec 2011 00:08:46 +1000 (EST) Message-ID: <4EDF6FE7.7050809@herveybayaustralia.com.au> Date: Wed, 07 Dec 2011 23:53:43 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 13:56:26 -0000 On 12/07/11 22:17, Tom Evans wrote: > On Wed, Dec 7, 2011 at 11:47 AM, Da Rock > wrote: >> I really hate sounding like an idiot, but if I don't ask I'll never know: >> The assembler in base is not up-to-date with the latest instruction sets for >> the cpu, and is causing an error because its telling the cpu to do something >> it doesn't understand and is going WTF! So the port binutils provides the >> latest instruction sets for the latest cpus. And ffmpeg and friends use the >> latest cpu abilities to run as fast as they do? Right or way off? Otherwise >> I'd have problems building anything, wouldn't I? > The way I understand it is that they use compiler/assembler features > that did not exist in the version of binutils that is in base. > > That might be related to CPU features - I know you need binutils from > ports to use SSE3 features, for example - but whether that is what > happens here, or whether it is due to ffmpeg using newer features > would have to be answered by someone who understands what is going on! > > Ok, that did just answer it. For starters SSE3 is used in ffmpeg/mplayer, but there would be more (3DNOW, etc). So that explains it... interesting study. I'll have a closer look at the docs on binutils to find out more. Cheers From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 14:22:31 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B2C1065679 for ; Wed, 7 Dec 2011 14:22:31 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E7E4E8FC18 for ; Wed, 7 Dec 2011 14:22:30 +0000 (UTC) Received: by vbbfr13 with SMTP id fr13so782414vbb.13 for ; Wed, 07 Dec 2011 06:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6tqkeNpxaSyiM1RnFh4CQFwah0Hj6xZ7ZEmZnndOv5A=; b=B0IOSii8uBGf+x35ElPFOVuQv3B/R8PUr368HmAp6J7Ch8OB7KD0y5nE8LSHdtyOrQ QGCi/JSN4FmUb2nfhd817C03LRKQk/GSTUn44EKjcCdHCkJ1Bp4HA+Fe9B7/2aNzU+zE /3pXmcxr3XNDgN7915mbJQ6poRRXZpo9IdQHE= MIME-Version: 1.0 Received: by 10.52.33.239 with SMTP id u15mr10797160vdi.49.1323267750085; Wed, 07 Dec 2011 06:22:30 -0800 (PST) Received: by 10.52.172.240 with HTTP; Wed, 7 Dec 2011 06:22:30 -0800 (PST) In-Reply-To: <4EDF6FAC.8000002@FreeBSD.org> References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF6FAC.8000002@FreeBSD.org> Date: Wed, 7 Dec 2011 14:22:30 +0000 Message-ID: From: Tom Evans To: Dimitry Andric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Da Rock , hackers@freebsd.org Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 14:22:31 -0000 On Wed, Dec 7, 2011 at 1:52 PM, Dimitry Andric wrote: > On 2011-12-07 01:40, Da Rock wrote: >> >> I'm trying to build some newer versions of ffserver. But I keep getting >> asm build errors when I get to libavcodec/vp*. >> >> Error: `(%esi,%eax)' is not a valid 64 bit base/index expression >> >> If I set it to build static it fails at h264. >> >> "Error: `-1(%edi)' =C2=A0is not a valid 64 bit base/index expression" >> >> Googling hasn't proved helpful in finding an answer. I've tried setting >> some configure options: arch=3Damd64/x86_64, disabling cmov/fast_cmov, >> ebx, etc. >> >> Any ideas how to fix this? > > > At first glance, I'd say you are compiling it with a 32-bit compiler or > assembler. > > In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, > and it compiles just fine with base gcc. =C2=A0What are the exact command= s > you are running? I imagine you are running CURRENT or 9.0, which has a newer binutils than 8-STABLE, which is what causes/exposes this issue. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 14:45:15 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66FAC106564A; Wed, 7 Dec 2011 14:45:15 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 171ED8FC0A; Wed, 7 Dec 2011 14:45:14 +0000 (UTC) Received: by iafi7 with SMTP id i7so1725375iaf.13 for ; Wed, 07 Dec 2011 06:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=TG0idJ+4achadFpyKYOEfc9tg9mxPLJfWYxFx7GRlKA=; b=Sw75PMoZ7BCbz+UjGQ2U+9HTeKGkDE+wWPUUui3AWlGXqR8HgDvJGZjbZT/ZwOpl8K lJsyr7lPYGEnGqCRl/niED/Wsfc88VKAeWyMJ3fumAuKC01eMmZsistiHZw/Dghbb4EL 7gtB0hUC3qRHTSLYpTDOjYNJ6J0EPnkNSM6H4= Received: by 10.42.163.8 with SMTP id a8mr18840541icy.57.1323269114516; Wed, 07 Dec 2011 06:45:14 -0800 (PST) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id el2sm7478442ibb.10.2011.12.07.06.45.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Dec 2011 06:45:12 -0800 (PST) References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF6FAC.8000002@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <16CC8DAA-66B0-47D8-9022-5DFFDA9A0198@gmail.com> X-Mailer: iPhone Mail (9A405) From: Garrett Cooper Date: Wed, 7 Dec 2011 06:45:08 -0800 To: Tom Evans Cc: Da Rock , "hackers@freebsd.org" , Dimitry Andric Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 14:45:15 -0000 On Dec 7, 2011, at 6:22 AM, Tom Evans wrote: > On Wed, Dec 7, 2011 at 1:52 PM, Dimitry Andric wrote: >> On 2011-12-07 01:40, Da Rock wrote: >>>=20 >>> I'm trying to build some newer versions of ffserver. But I keep getting >>> asm build errors when I get to libavcodec/vp*. >>>=20 >>> Error: `(%esi,%eax)' is not a valid 64 bit base/index expression >>>=20 >>> If I set it to build static it fails at h264. >>>=20 >>> "Error: `-1(%edi)' is not a valid 64 bit base/index expression" >>>=20 >>> Googling hasn't proved helpful in finding an answer. I've tried setting >>> some configure options: arch=3Damd64/x86_64, disabling cmov/fast_cmov, >>> ebx, etc. >>>=20 >>> Any ideas how to fix this? >>=20 >>=20 >> At first glance, I'd say you are compiling it with a 32-bit compiler or >> assembler. >>=20 >> In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, >> and it compiles just fine with base gcc. What are the exact commands >> you are running? >=20 > I imagine you are running CURRENT or 9.0, which has a newer binutils > than 8-STABLE, which is what causes/exposes this issue. The question is: what is the OP running? I don't think that's been identifie= d yet.. Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 16:41:46 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D507106564A for ; Wed, 7 Dec 2011 16:41:46 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 01BDA8FC0C for ; Wed, 7 Dec 2011 16:41:45 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so1535132wgb.31 for ; Wed, 07 Dec 2011 08:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=My2L3KcHAC+NpKtmpedoMStIDnBwk5OtVSkBf8cMBtw=; b=E5fbsMrlJZwZ62cy4cJlnfP9IA6B5PfZsbgb3H7mAXRMC0SeIM/PLJskZjFKCwZPUV rdB/tWRC1XkvLrHMu5dBphc5eZK2u11UMSvviGq7H4LFTms61ybHXnV+8V5+F5lx2fCv qp3+QzlbZg8QTpzs/hwzY2QUcP4lqjeqEe9L0= Received: by 10.227.198.19 with SMTP id em19mr7924633wbb.14.1323276104821; Wed, 07 Dec 2011 08:41:44 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id ca18sm3651649wib.13.2011.12.07.08.41.40 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 08:41:41 -0800 (PST) Message-ID: <20111207.164141.027.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Wed, 07 Dec 2011 17:41:41 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20111205.171654.020.1@DOMY-PC> <20111206.170342.731.2@DOMY-PC> X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:41:46 -0000 > > Time is SAME as with generic binaries, but score is just a 1.2 = higher,=0D=0A> which is too small to be relevant.=0D=0A> > What do you = think about this?=0D=0A> >=0D=0A> =0D=0A> I think this is why most people = don't bother with setting CPUTYPE ;)=0D=0A> =0D=0A> Chris=0D=0A> = =0D=0A=0D=0ADUH!=0D=0AWhy you didn't told me that right away. instead = making me into "ALL THIS"!=0D=0AYes, yes, very funy! I'll remember = this!=0D=0A:P=0D=0A=0D=0A> As usual, it very well *may* be true, but = please use ministat(1) to=0D=0A> confirm. This requires more than one = test. I'm not trying to be=0D=0A> difficult - but statistics and = benchmarking is non-trivial.=0D=0A> =0D=0A> -- =0D=0A> Eitan = Adler=0D=0A=0D=0AI understand and have read your link about statistics = and benchmarking ...=0D=0AYes, I agree. It is science for = itself.=0D=0A=0D=0AI've never heard for ministat(1) and will throw an eye = on:=0D=0A=0D=0A> A few other good suggestions:=0D=0A> =0D=0A> = http://wiki.freebsd.org/BenchmarkAdvice=0D=0A> =0D=0A> - Max=0D=0A> = =0D=0A=0D=0A=0D=0AI would like to ask a few questions, regarding setting = up ENVIROMENT for benchmarking, regardless of what will be = benched!=0D=0AThat is, point where benchmarking hasn't even = started!=0D=0A=0D=0AI see it should be SUM (single user mode), with = enabled, only essential "things"=0D=0AShould it be a regular or MD ROOT = based SUM (FreeBSD running in RAM)=0D=0A=0D=0A=0D=0ADomagoj = Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 20:10:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDA4B1065726 for ; Wed, 7 Dec 2011 20:10:21 +0000 (UTC) (envelope-from mwm@mired.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4718FC18 for ; Wed, 7 Dec 2011 20:10:20 +0000 (UTC) Received: by iafi7 with SMTP id i7so2291709iaf.13 for ; Wed, 07 Dec 2011 12:10:20 -0800 (PST) Received: by 10.231.41.69 with SMTP id n5mr4823973ibe.92.1323287280368; Wed, 07 Dec 2011 11:48:00 -0800 (PST) Received: from mikmeyer-vm-fedora (dhcp-173-37-11-193.cisco.com. [173.37.11.193]) by mx.google.com with ESMTPS id cz1sm10030864ibb.11.2011.12.07.11.47.59 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 11:47:59 -0800 (PST) Date: Wed, 7 Dec 2011 11:47:56 -0800 From: Mike Meyer To: freebsd-hackers@freebsd.org Message-ID: <20111207114756.48295690@mikmeyer-vm-fedora> In-Reply-To: References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.7; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:10:21 -0000 On Wed, 7 Dec 2011 12:17:57 +0000 Tom Evans wrote: > The way I understand it is that they use compiler/assembler features > that did not exist in the version of binutils that is in base. Which begs the question - why isn't the new version of the tools (provided by ports) listed in BUILDDEPENDS in the port, then? Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE0A1106564A for ; Wed, 7 Dec 2011 21:00:00 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4452B8FC0A for ; Wed, 7 Dec 2011 20:59:59 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so1929643wgb.31 for ; Wed, 07 Dec 2011 12:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=miDwTw8TXunWnUr1F0kGIowiE9o5VAlSTWGbb+2G37Y=; b=RFDQicIH32rSGQDqMjyBavLWYj6PGE9Ftif05YS29esxHZw0c0wQY5eDxnoEMvjgmC 85Bjgzy4/GQ1N1QltPQG0LOoP/n0tUC00WbKxwiEyCh3vvSmh8pzwYXs5fV4sFliDbPn SVcovLsL/rulfbux5z8iSDRkKTx8v67qYBs74= MIME-Version: 1.0 Received: by 10.216.1.68 with SMTP id 46mr14520wec.23.1323289713689; Wed, 07 Dec 2011 12:28:33 -0800 (PST) Received: by 10.180.94.2 with HTTP; Wed, 7 Dec 2011 12:28:33 -0800 (PST) In-Reply-To: <20111119100150.GA1560@reks> References: <20111119100150.GA1560@reks> Date: Wed, 7 Dec 2011 15:28:33 -0500 Message-ID: From: Arnaud Lacombe To: Gleb Kurtsou Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, mdf@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 21:00:00 -0000 Hi, On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou wrote: > Hi, > > I was lucky to write a bit of code which gcc 4.2 fails to compile > correctly with -O2. Too keep long story short the code fails for gcc > from base system and last gcc 4.2 snapshot from ports. It works with gcc > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > -Os optimization levels are fine (I've tried with all -f* flags > mentioned in documentation) > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > presume i386 should be fine. These options are also used for > compilation of kernel (with debugging enabled) and modules. > > I'm not able to share the code, but have a test case reproducing the > bug. I've encountered the issue over a week ago and tried narrowing it down > to a simple test I could share but without much success. > > The code itself is very common: initialize two structs on stack, call a > function with pointers to those stucts as arguments. A number of inlined > assertion functions. gcc fails to correctly optimize struct assignments > with -fno-omit-frame-pointer, I have a number of small structs assigned, > gcc decides not to use data coping but to assign fields directly. I've > tried disabling sra, tweaking sra parameters -- no luck in forcing it > to copy data. Replacing one particular assignment with memcpy produces > correct code, but that's not a solution. > > -O2 -fno-omit-frame-pointer -fno-inline is buggy > -O2 -fno-omit-frame-pointer -frename-registers is buggy > > I found similar issue with gcc 4.6, but I'm not able to reproduce it > with gcc test case: > https://bugzilla.redhat.com/show_bug.cgi?id=679924 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 > this PR seems highly irrelevant, the cause has been identified to a commit made in mid-2010, that's 3 years older than gcc in base. > I'll be glad to help debugging it and will be hanging on #bsddev during > weekend as glk. > at least, can you share the testcase and miscompilation details ? Thanks, - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 22:32:09 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9061B106566B for ; Wed, 7 Dec 2011 22:32:09 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2E98FC14 for ; Wed, 7 Dec 2011 22:32:08 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 49C855C24; Thu, 8 Dec 2011 08:44:30 +1000 (EST) Message-ID: <4EDFE8C6.7080206@herveybayaustralia.com.au> Date: Thu, 08 Dec 2011 08:29:26 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: Garrett Cooper References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF6FAC.8000002@FreeBSD.org> <16CC8DAA-66B0-47D8-9022-5DFFDA9A0198@gmail.com> In-Reply-To: <16CC8DAA-66B0-47D8-9022-5DFFDA9A0198@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tom Evans , "hackers@freebsd.org" , Dimitry Andric Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 22:32:09 -0000 On 12/08/11 00:45, Garrett Cooper wrote: > On Dec 7, 2011, at 6:22 AM, Tom Evans wrote: > >> On Wed, Dec 7, 2011 at 1:52 PM, Dimitry Andric wrote: >>> On 2011-12-07 01:40, Da Rock wrote: >>>> I'm trying to build some newer versions of ffserver. But I keep getting >>>> asm build errors when I get to libavcodec/vp*. >>>> >>>> Error: `(%esi,%eax)' is not a valid 64 bit base/index expression >>>> >>>> If I set it to build static it fails at h264. >>>> >>>> "Error: `-1(%edi)' is not a valid 64 bit base/index expression" >>>> >>>> Googling hasn't proved helpful in finding an answer. I've tried setting >>>> some configure options: arch=amd64/x86_64, disabling cmov/fast_cmov, >>>> ebx, etc. >>>> >>>> Any ideas how to fix this? >>> >>> At first glance, I'd say you are compiling it with a 32-bit compiler or >>> assembler. >>> >>> In any case, I downloaded the latest version (0.8.7) from ffmpeg.org, >>> and it compiles just fine with base gcc. What are the exact commands >>> you are running? >> I imagine you are running CURRENT or 9.0, which has a newer binutils >> than 8-STABLE, which is what causes/exposes this issue. > The question is: what is the OP running? I don't think that's been identified yet.. > For reference 8.1 and 8.2. I'll post once I've had a chance to confirm the solution, but I'm pretty sure it will solve it based on the info I've been given. Cheers From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 22:33:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB76F106566B for ; Wed, 7 Dec 2011 22:33:57 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9878FC13 for ; Wed, 7 Dec 2011 22:33:57 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id EC7555C27 for ; Thu, 8 Dec 2011 08:46:18 +1000 (EST) Message-ID: <4EDFE933.3060708@herveybayaustralia.com.au> Date: Thu, 08 Dec 2011 08:31:15 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> <20111207114756.48295690@mikmeyer-vm-fedora> In-Reply-To: <20111207114756.48295690@mikmeyer-vm-fedora> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 22:33:57 -0000 On 12/08/11 05:47, Mike Meyer wrote: > On Wed, 7 Dec 2011 12:17:57 +0000 > Tom Evans wrote: >> The way I understand it is that they use compiler/assembler features >> that did not exist in the version of binutils that is in base. > Which begs the question - why isn't the new version of the tools > (provided by ports) listed in BUILDDEPENDS in the port, then? > I'm not building the port. This is my own build, so the builddepends isn't existent. From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 7 22:36:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0961F1065670 for ; Wed, 7 Dec 2011 22:36:16 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id ABBA98FC17 for ; Wed, 7 Dec 2011 22:36:15 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 267475C27 for ; Thu, 8 Dec 2011 08:48:37 +1000 (EST) Message-ID: <4EDFE9BD.9020105@herveybayaustralia.com.au> Date: Thu, 08 Dec 2011 08:33:33 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> <20111207114756.48295690@mikmeyer-vm-fedora> <4EDFE933.3060708@herveybayaustralia.com.au> In-Reply-To: <4EDFE933.3060708@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 64bit build errors X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 22:36:16 -0000 On 12/08/11 08:31, Da Rock wrote: > On 12/08/11 05:47, Mike Meyer wrote: >> On Wed, 7 Dec 2011 12:17:57 +0000 >> Tom Evans wrote: >>> The way I understand it is that they use compiler/assembler features >>> that did not exist in the version of binutils that is in base. >> Which begs the question - why isn't the new version of the tools >> (provided by ports) listed in BUILDDEPENDS in the port, then? >> > I'm not building the port. This is my own build, so the builddepends > isn't existent. Hence hackers@, else I would have posted ports@ From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 06:08:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1151065670 for ; Thu, 8 Dec 2011 06:08:01 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 276568FC17 for ; Thu, 8 Dec 2011 06:08:00 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 164F65C24 for ; Thu, 8 Dec 2011 16:20:22 +1000 (EST) Message-ID: <4EE0539E.3030406@herveybayaustralia.com.au> Date: Thu, 08 Dec 2011 16:05:18 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> <20111207114756.48295690@mikmeyer-vm-fedora> <4EDFE933.3060708@herveybayaustralia.com.au> <4EDFE9BD.9020105@herveybayaustralia.com.au> In-Reply-To: <4EDFE9BD.9020105@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [SOLVED]Re: 64bit build errors - use gcc46 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 06:08:01 -0000 On 12/08/11 08:33, Da Rock wrote: > On 12/08/11 08:31, Da Rock wrote: >> On 12/08/11 05:47, Mike Meyer wrote: >>> On Wed, 7 Dec 2011 12:17:57 +0000 >>> Tom Evans wrote: >>>> The way I understand it is that they use compiler/assembler features >>>> that did not exist in the version of binutils that is in base. >>> Which begs the question - why isn't the new version of the tools >>> (provided by ports) listed in BUILDDEPENDS in the port, then? >>> >> I'm not building the port. This is my own build, so the builddepends >> isn't existent. > Hence hackers@, else I would have posted ports@ Just to let the list know, I changed as - ./configure --as=/usr/local/bin/as. I still had the exact same error oddly enough. I then had to install gcc46; and the error changed. I then had to update the configure script to comment out the v4l videodev headers (weird). Bingo! I had success. So, it begs the question did the as option change things? Or does gcc46 imply the use of it anyway? I'll have to try again without the option to see for sure, but for now I have another project that I need to keep the status quo for. From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 06:16:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0F43106564A for ; Thu, 8 Dec 2011 06:16:51 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 65A698FC13 for ; Thu, 8 Dec 2011 06:16:50 +0000 (UTC) Received: by eaai12 with SMTP id i12so1282205eaa.13 for ; Wed, 07 Dec 2011 22:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MrWeZ0Gvez9nn6wvnHS181EAai/f7bbQrtLD2kZ0WLc=; b=n85eXr9XP8oMY3aACaChbYRJejGcCAWilSaYayi75ublZ9woIJLkYwlLThestlWxql rZUin+NveHORpZzOj788R1vBU4cYvcF2xnBPaDKAGkrUV1qkAhfmA/BkBTHI7VBqXmaT nRluaTCzLh0xXV81ZGAyisFGkIk66A/qkchYU= MIME-Version: 1.0 Received: by 10.213.21.148 with SMTP id j20mr65919ebb.87.1323325009814; Wed, 07 Dec 2011 22:16:49 -0800 (PST) Received: by 10.14.47.194 with HTTP; Wed, 7 Dec 2011 22:16:49 -0800 (PST) In-Reply-To: References: <868vqt0xuc.fsf@gmail.com> <1313663436600-4711635.post@n5.nabble.com> <86hb5euofp.fsf@gmail.com> <20110823175133.GK18091@acme.spoerlein.net> Date: Thu, 8 Dec 2011 00:16:49 -0600 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 06:16:51 -0000 Hi, I uploaded a new version, 2.0.2. http://students.cs.niu.edu/~z1565938/distfiles/nvi2-freebsd-2011-12-07.diff.gz Same as before, you need to remove usr.bin/vi/port.h after you applied this patch. In this version, I analyzed all of the PRs, patches/commits of Debian's nvi package and NetBSD's nvi-1.81.6b5 in base. Many bug fixes are merged. And 2 main features are gained: 1. Recognized non-ASCII letters' upper/lower cases (~); 2. Recognized non-ASCII word boundary (w, ^A, regex, etc.). Btw, vim don't have such features. I also solved all memory leak in all know tests. iconv_open(3) usage part is rewrote. 2 changes from NetBSD are not merged: 1. To use signed char instead of unsigned char in 8-bit mode. This requires to cast all character to at least unsigned char when passing them to ctype(3). Test cases are required to convince me on this part; 2. 32-bit clean regex. According to the PRs and commit log, I don't have enough confidence in NetBSD's code here. Although the current regex in use is only 24-bit clean, but it works correctly and, my final solution is to use TRE in base directly. Comments and test reports are welcome. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 08:55:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45FCA1065670; Thu, 8 Dec 2011 08:55:45 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id E6F508FC15; Thu, 8 Dec 2011 08:55:44 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 7A8DFEBE32; Thu, 8 Dec 2011 09:37:02 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Z1Qh90lUHC2p; Thu, 8 Dec 2011 09:37:01 +0100 (CET) Received: from [10.0.0.79] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 1DF74EBD4D; Thu, 8 Dec 2011 09:37:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: Date: Thu, 8 Dec 2011 09:37:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111119100150.GA1560@reks> To: Arnaud Lacombe X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Piotr Nowak , mdf@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:55:45 -0000 On 2011-12-07, at 21:28, Arnaud Lacombe wrote: > Hi, >=20 > On Sat, Nov 19, 2011 at 5:01 AM, Gleb Kurtsou = wrote: >> Hi, >>=20 >> I was lucky to write a bit of code which gcc 4.2 fails to compile >> correctly with -O2. Too keep long story short the code fails for gcc >> from base system and last gcc 4.2 snapshot from ports. It works with = gcc >> 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O = and >> -Os optimization levels are fine (I've tried with all -f* flags >> mentioned in documentation) >>=20 >> -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I >> presume i386 should be fine. These options are also used for >> compilation of kernel (with debugging enabled) and modules. >>=20 >> I'm not able to share the code, but have a test case reproducing the >> bug. I've encountered the issue over a week ago and tried narrowing = it down >> to a simple test I could share but without much success. >>=20 >> The code itself is very common: initialize two structs on stack, call = a >> function with pointers to those stucts as arguments. A number of = inlined >> assertion functions. gcc fails to correctly optimize struct = assignments >> with -fno-omit-frame-pointer, I have a number of small structs = assigned, >> gcc decides not to use data coping but to assign fields directly. = I've >> tried disabling sra, tweaking sra parameters -- no luck in forcing it >> to copy data. Replacing one particular assignment with memcpy = produces >> correct code, but that's not a solution. >>=20 >> -O2 -fno-omit-frame-pointer -fno-inline is buggy >> -O2 -fno-omit-frame-pointer -frename-registers is buggy >>=20 >> I found similar issue with gcc 4.6, but I'm not able to reproduce it >> with gcc test case: >> https://bugzilla.redhat.com/show_bug.cgi?id=3D679924 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47893 >>=20 > this PR seems highly irrelevant, the cause has been identified to a > commit made in mid-2010, that's 3 years older than gcc in base. >=20 >> I'll be glad to help debugging it and will be hanging on #bsddev = during >> weekend as glk. >>=20 > at least, can you share the testcase and miscompilation details ? I believe we suffer from a very similar issue on PowerPC as well, we'll = provide detailed information shortly. Rafal From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 09:46:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F1681065673; Thu, 8 Dec 2011 09:46:21 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C3D048FC12; Thu, 8 Dec 2011 09:46:20 +0000 (UTC) Received: by lagv3 with SMTP id v3so854886lag.13 for ; Thu, 08 Dec 2011 01:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RR0OtEp4MnicPtpyDAMc/0Mdh24FJpQHvZyz/Nk90pk=; b=UmpB0ti/f3t8OQ/bkC06lC69ywS1AWMHhuH4tgIpYOqJKMZ4CgGN9MbrZH0p6os8nh 7nBKiJ1vJGkIbRmw8jUYne6zYKsfIkY9MLLFpSVqmQZEeJTmxd8kB0wugI8Zz7dzMDBj Aid4HFDSrsWVF8KasR8KnruODA8xt6H0gJcQQ= Received: by 10.152.104.206 with SMTP id gg14mr1396976lab.41.1323337578765; Thu, 08 Dec 2011 01:46:18 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id no9sm4182289lab.0.2011.12.08.01.46.16 (version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 01:46:18 -0800 (PST) Date: Thu, 8 Dec 2011 11:46:18 +0200 From: Gleb Kurtsou To: Piotr Nowak Message-ID: <20111208094618.GA11139@reks> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111208090159.GA1924@cq1> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rafal Jaworowski , mdf@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:46:21 -0000 On (08/12/2011 10:01), Piotr Nowak wrote: > We're working on PowerPC target using GCC 4.2.1 > and FreeBSD 6.1. It seems like we have similar > problem. In our case GCC sometimes very unfortunately > optimize code with -fno-omit-frame-pointer. > > Example shown below covers file sys/powerc/booke/pmap.c > and function pmap_kenter. If we disassemble kernel binary > we have: > > c019998c: 4b ec 6a ed bl c0060478 <_mtx_unlock_spin_flags> > c0199990: 81 61 00 00 lwz r11,0(r1) > c0199994: 80 0b 00 04 lwz r0,4(r11) > c0199998: 7d 61 5b 78 mr r1,r11 > c019999c: 82 ab ff d4 lwz r21,-44(r11) > c01999a0: 7c 08 03 a6 mtlr r0 > c01999a4: 82 cb ff d8 lwz r22,-40(r11) > c01999a8: 82 eb ff dc lwz r23,-36(r11) > c01999ac: 83 0b ff e0 lwz r24,-32(r11) > c01999b0: 83 2b ff e4 lwz r25,-28(r11) > c01999b4: 83 4b ff e8 lwz r26,-24(r11) > c01999b8: 83 6b ff ec lwz r27,-20(r11) > > As you can see stack pointer on R1 is being updated > before stashed data were pulled off stack. (mr r1,r11) > As a result of this we have chance to get crash when > any interrupt hit shortly after stack pointer update. > The interrupt prologue will override not yet pulled off > pmap_kenter function data. > > The problem occures only with -fno-omit-frame-pointer > and not every branch returns are beeing corrupted. > > Do you think this issue may be somehow related to yours? > Are there any patches/solutions to fix it? Adding -finline-functions fixed/masked issue for me. Unfortunately building kernel with -finline-functions is not supported. You can try tweaking conf/files to change build options for this file only. Issue not sra-related, but sra is also known to be buggy in gcc 4.2. > > Regards, > Piotr From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 09:58:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 836DA106564A for ; Thu, 8 Dec 2011 09:58:07 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D7A98FC08 for ; Thu, 8 Dec 2011 09:58:07 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2151773vcb.13 for ; Thu, 08 Dec 2011 01:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CMQs5iYqVbA22vGYCQvlsbEHfOsVKlLl9swD5YJFl0o=; b=t23CrpN3/3IFwuvf7x1OsmwAi4IOSl/+RISTc3dIeLmQV6LzvB601jPn2MXmuTnzNj +CLA7LpYWkxFpgFrEw3PPvbip7iPDQY2Xzoj6JjjZcpCg8nlQOG6+BbhE9swtGPS3M8E JnCcK+xek+FC9vg6EKlQT2aQuKsyZ+t+C+et8= MIME-Version: 1.0 Received: by 10.52.117.65 with SMTP id kc1mr1144513vdb.66.1323338286531; Thu, 08 Dec 2011 01:58:06 -0800 (PST) Received: by 10.52.172.240 with HTTP; Thu, 8 Dec 2011 01:58:06 -0800 (PST) In-Reply-To: <4EE0539E.3030406@herveybayaustralia.com.au> References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> <20111207114756.48295690@mikmeyer-vm-fedora> <4EDFE933.3060708@herveybayaustralia.com.au> <4EDFE9BD.9020105@herveybayaustralia.com.au> <4EE0539E.3030406@herveybayaustralia.com.au> Date: Thu, 8 Dec 2011 09:58:06 +0000 Message-ID: From: Tom Evans To: Da Rock Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: [SOLVED]Re: 64bit build errors - use gcc46 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:58:07 -0000 On Thu, Dec 8, 2011 at 6:05 AM, Da Rock wrote: > > Just to let the list know, I changed as - ./configure > --as=/usr/local/bin/as. I still had the exact same error oddly enough. > > I then had to install gcc46; and the error changed. > > I then had to update the configure script to comment out the v4l videodev > headers (weird). Bingo! I had success. > > So, it begs the question did the as option change things? Or does gcc46 > imply the use of it anyway? > > I'll have to try again without the option to see for sure, but for now I > have another project that I need to keep the status quo for. Yes, sometimes as is invoked via gcc, and if you are using the stock gcc, it uses the stock as, and you still get the errors. You need both gcc46 and binutils from ports. Sorry, forgot that bit :o Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 09:20:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E712106566B; Thu, 8 Dec 2011 09:20:45 +0000 (UTC) (envelope-from pn@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id F1F2E8FC18; Thu, 8 Dec 2011 09:20:44 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 768ACEBE32; Thu, 8 Dec 2011 10:02:01 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id zMvwqWvgQqTv; Thu, 8 Dec 2011 10:02:00 +0100 (CET) Received: from cq1 (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id BE2F9EBD4D; Thu, 8 Dec 2011 10:02:00 +0100 (CET) Date: Thu, 8 Dec 2011 10:01:59 +0100 From: Piotr Nowak To: Rafal Jaworowski Message-ID: <20111208090159.GA1924@cq1> References: <20111119100150.GA1560@reks> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 08 Dec 2011 12:13:46 +0000 Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Arnaud Lacombe , mdf@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:20:45 -0000 We're working on PowerPC target using GCC 4.2.1 and FreeBSD 6.1. It seems like we have similar problem. In our case GCC sometimes very unfortunately optimize code with -fno-omit-frame-pointer. Example shown below covers file sys/powerc/booke/pmap.c and function pmap_kenter. If we disassemble kernel binary we have: c019998c: 4b ec 6a ed bl c0060478 <_mtx_unlock_spin_flags> c0199990: 81 61 00 00 lwz r11,0(r1) c0199994: 80 0b 00 04 lwz r0,4(r11) c0199998: 7d 61 5b 78 mr r1,r11 c019999c: 82 ab ff d4 lwz r21,-44(r11) c01999a0: 7c 08 03 a6 mtlr r0 c01999a4: 82 cb ff d8 lwz r22,-40(r11) c01999a8: 82 eb ff dc lwz r23,-36(r11) c01999ac: 83 0b ff e0 lwz r24,-32(r11) c01999b0: 83 2b ff e4 lwz r25,-28(r11) c01999b4: 83 4b ff e8 lwz r26,-24(r11) c01999b8: 83 6b ff ec lwz r27,-20(r11) As you can see stack pointer on R1 is being updated before stashed data were pulled off stack. (mr r1,r11) As a result of this we have chance to get crash when any interrupt hit shortly after stack pointer update. The interrupt prologue will override not yet pulled off pmap_kenter function data. The problem occures only with -fno-omit-frame-pointer and not every branch returns are beeing corrupted. Do you think this issue may be somehow related to yours? Are there any patches/solutions to fix it? Regards, Piotr From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 13:20:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44D2A1065680 for ; Thu, 8 Dec 2011 13:20:41 +0000 (UTC) (envelope-from freebsd-hackers@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id E20648FC0A for ; Thu, 8 Dec 2011 13:20:40 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 6717F5C24 for ; Thu, 8 Dec 2011 23:33:02 +1000 (EST) Message-ID: <4EE0B905.1050505@herveybayaustralia.com.au> Date: Thu, 08 Dec 2011 23:17:57 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4EDEB600.9000102@herveybayaustralia.com.au> <4EDF4703.1050705@herveybayaustralia.com.au> <4EDF5253.5060201@herveybayaustralia.com.au> <20111207114756.48295690@mikmeyer-vm-fedora> <4EDFE933.3060708@herveybayaustralia.com.au> <4EDFE9BD.9020105@herveybayaustralia.com.au> <4EE0539E.3030406@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [SOLVED]Re: 64bit build errors - use gcc46 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 13:20:41 -0000 On 12/08/11 19:58, Tom Evans wrote: > On Thu, Dec 8, 2011 at 6:05 AM, Da Rock > wrote: >> Just to let the list know, I changed as - ./configure >> --as=/usr/local/bin/as. I still had the exact same error oddly enough. >> >> I then had to install gcc46; and the error changed. >> >> I then had to update the configure script to comment out the v4l videodev >> headers (weird). Bingo! I had success. >> >> So, it begs the question did the as option change things? Or does gcc46 >> imply the use of it anyway? >> >> I'll have to try again without the option to see for sure, but for now I >> have another project that I need to keep the status quo for. > Yes, sometimes as is invoked via gcc, and if you are using the stock > gcc, it uses the stock as, and you still get the errors. You need both > gcc46 and binutils from ports. > > Sorry, forgot that bit :o > > Confirmed. Built without --as and only --cc arguments. Great learning experience for me anyway... :) Cheers From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 13:23:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F1F1065778 for ; Thu, 8 Dec 2011 13:23:18 +0000 (UTC) (envelope-from miciamail@hotmail.it) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by mx1.freebsd.org (Postfix) with ESMTP id 0C25B8FC08 for ; Thu, 8 Dec 2011 13:23:17 +0000 (UTC) Received: from BLU0-SMTP315 ([65.55.111.72]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 05:10:53 -0800 X-Originating-IP: [78.13.148.220] X-Originating-Email: [miciamail@hotmail.it] Message-ID: Received: from [192.168.1.102] ([78.13.148.220]) by BLU0-SMTP315.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 05:10:51 -0800 From: Lorenzo Cogotti To: freebsd-hackers Date: Thu, 8 Dec 2011 14:09:47 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2011 13:10:51.0886 (UTC) FILETIME=[CF98B0E0:01CCB5AA] Subject: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 13:23:18 -0000 Dear all, I am new to this list and to FreeBSD in general, so first of all hi everyone and thank you for providing this awesome and rock solid OS. I have a CDC compliant (at least this is what the manufacturer claims) USB Modem, which doesn't get detected by cdce module. /var/log/messages reports: root: Unknown USB device: vendor 0x0451 product 0x6060 bus uhub0 kernel: ugen0.2: at usbus0 usbconfig list reports: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON I tested this with FreeBSD 8.2 and FreeBSD 9.0RC2, the situation doesn't change. I tested this modem on Linux, which is able to detect and properly use this modem via USB with module: cdc_ether I suspect that some trivial changes to cdce module would get this modem up and running, but I am too newbie to do this on my own, so I thought to ask this ML for help on this topic. I took a look to cdce, on kernel sources included with FreeBSD 8.2 release, more precisely to: dev/usb/net/if_cdce.c I assume that a device specific entry to: static const struct usb_device_id cdce_devs[] would do the trick, wouldn't it? How should I edit this file in a sane way and test if this device get recognized? I tried some USB_VPI combinations adding the afore mentioned identifiers from /var/log/messages, the device got recognized correctly by cdce, but the dhclient command hanged as if the communication with the device failed. I am currently on a fresh, just installed, FreeBSD 8.2 AMD64 system. Sorry if I missed to report some crucial information, if so, please let me know. Regards. -- Lorenzo Cogotti From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 14:41:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E20E1065675 for ; Thu, 8 Dec 2011 14:41:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 20C788FC15 for ; Thu, 8 Dec 2011 14:41:46 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 213145416; Thu, 08 Dec 2011 15:41:44 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 8 Dec 2011 15:39:10 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112081539.11014.hselasky@c2i.net> Cc: Lorenzo Cogotti Subject: Re: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:41:47 -0000 On Thursday 08 December 2011 14:09:47 Lorenzo Cogotti wrote: > Dear all, > > I am new to this list and to FreeBSD in general, so first of all hi > everyone and thank you for providing this awesome and rock solid OS. > > I have a CDC compliant (at least this is what the manufacturer claims) > USB Modem, which doesn't get detected by cdce module. > > /var/log/messages reports: > root: Unknown USB device: vendor 0x0451 product 0x6060 bus uhub0 > kernel: ugen0.2: at usbus0 > > usbconfig list reports: > ugen0.2: > at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > I tested this with FreeBSD 8.2 and FreeBSD 9.0RC2, the situation doesn't > change. > I tested this modem on Linux, which is able to detect and properly use > this modem via USB with module: cdc_ether > > I suspect that some trivial changes to cdce module would get this modem > up and running, but I am too newbie to do this on my own, so I thought > to ask this ML for help on this topic. > > I took a look to cdce, on kernel sources included with FreeBSD 8.2 > release, more precisely to: > dev/usb/net/if_cdce.c > Hi, > I assume that a device specific entry to: Typically you need to select configuration 1 for dual RNDIS/CDCE devices to work. 1) Locate your device: usbconfig 2) Set config 1 usbconfig -d X.Y set_config 1 To permanently do this, you can set the configuration index 1 quirk for your device. --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 15:36:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 866351065672 for ; Thu, 8 Dec 2011 15:36:54 +0000 (UTC) (envelope-from miciamail@hotmail.it) Received: from blu0-omc1-s8.blu0.hotmail.com (blu0-omc1-s8.blu0.hotmail.com [65.55.116.19]) by mx1.freebsd.org (Postfix) with ESMTP id 45D6B8FC0C for ; Thu, 8 Dec 2011 15:36:54 +0000 (UTC) Received: from BLU0-SMTP147 ([65.55.116.9]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 07:36:53 -0800 X-Originating-IP: [78.13.148.220] X-Originating-Email: [miciamail@hotmail.it] Message-ID: Received: from [192.168.1.102] ([78.13.148.220]) by BLU0-SMTP147.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 07:36:52 -0800 From: Lorenzo Cogotti To: freebsd-hackers@freebsd.org Date: Thu, 8 Dec 2011 16:35:47 +0100 In-Reply-To: <201112081539.11014.hselasky@c2i.net> References: <201112081539.11014.hselasky@c2i.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2011 15:36:52.0321 (UTC) FILETIME=[3538FD10:01CCB5BF] Cc: Hans Petter Selasky Subject: Re: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:36:54 -0000 Il giorno gio, 08/12/2011 alle 15.39 +0100, Hans Petter Selasky ha scritto: > Typically you need to select configuration 1 for dual RNDIS/CDCE devices to > work. > > 1) Locate your device: > > usbconfig > > 2) Set config 1 > > usbconfig -d X.Y set_config 1 > > To permanently do this, you can set the configuration index 1 quirk for your > device. > I tried editing if_cdce.c adding to the static array mentioned in my first mail: {USB_VPI(USB_VENDOR_TI, 0x6060, 0)}, obviously if this edit is necessary, a nice good little #define for 0x6060 should be added where appropriate. The device get detected and properly claimed by the cdce module. It is all good unless I actually try to connect with: dhclient ue0 When I try this, the DHCP request just hangs and times out. I tried usbconfig -d 0.2 set_config 1 This produces: cdce0: at uhub0, port 3, addr 2 (disconnected) cdce0: on usbus0 ue0: on cdce0 ue0: Ethernet address: 00:e1:a7:76:76:81 cdce1: on usbus0 cdce1: No valid alternate setting found device_attach: cdce1 attach returned 6 cdce1: on usbus0 cdce1: No valid alternate setting found device_attach: cdce1 attach returned 6 Despite this moltitude of scary messages, dhclient now works good and I can surf with my USB modem on FreeBSD, which is as awesome as it sounds. So, the questions now are: 1) was the if_cdce.c edit necessary, or the usbconfig is more than enough? 2) how/should could this stuff be made in an automagic way by FreeBSD? Since everything I have on this desktop has been detected flawlessly, this was the only thing that made me suffer. -- Lorenzo Cogotti From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 15:55:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2645106566B for ; Thu, 8 Dec 2011 15:55:46 +0000 (UTC) (envelope-from miciamail@hotmail.it) Received: from blu0-omc1-s13.blu0.hotmail.com (blu0-omc1-s13.blu0.hotmail.com [65.55.116.24]) by mx1.freebsd.org (Postfix) with ESMTP id B264C8FC15 for ; Thu, 8 Dec 2011 15:55:46 +0000 (UTC) Received: from BLU0-SMTP138 ([65.55.116.9]) by blu0-omc1-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 07:55:45 -0800 X-Originating-IP: [78.13.148.220] X-Originating-Email: [miciamail@hotmail.it] Message-ID: Received: from [192.168.1.102] ([78.13.148.220]) by BLU0-SMTP138.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Dec 2011 07:55:44 -0800 From: Lorenzo Cogotti To: freebsd-hackers@freebsd.org Date: Thu, 8 Dec 2011 16:54:40 +0100 In-Reply-To: References: <201112081539.11014.hselasky@c2i.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2011 15:55:45.0086 (UTC) FILETIME=[D86735E0:01CCB5C1] Cc: Hans Petter Selasky Subject: Re: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:55:47 -0000 Il giorno gio, 08/12/2011 alle 16.35 +0100, Lorenzo Cogotti ha scritto: > I tried editing if_cdce.c adding to the static array mentioned in my > first mail: > > {USB_VPI(USB_VENDOR_TI, 0x6060, 0)}, > I tried to remove this edit and recompile the kernel module, the scary messages faded away, leaving a nice and happy: cdce0 on usbus0 ue0: on cdce0 ue0: Ethernet address: ... This is just perfect. So it appears that the edit is absolutely not necessary. The only thing that seems to be necessary is setting the configuration to 1 as a quirk. Where should I look to do that? Eventually, should I send a patch to someone so that I am not the only one to benefit from your help? -- Lorenzo Cogotti From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 15:57:07 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23D5106567A for ; Thu, 8 Dec 2011 15:57:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC548FC18 for ; Thu, 8 Dec 2011 15:57:06 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 213190603; Thu, 08 Dec 2011 16:57:05 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 8 Dec 2011 16:54:31 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201112081539.11014.hselasky@c2i.net> In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112081654.31641.hselasky@c2i.net> Cc: Lorenzo Cogotti Subject: Re: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 15:57:08 -0000 On Thursday 08 December 2011 16:35:47 Lorenzo Cogotti wrote: > Il giorno gio, 08/12/2011 alle 15.39 +0100, Hans Petter Selasky ha > > scritto: > > Typically you need to select configuration 1 for dual RNDIS/CDCE devices > > to work. > > > > 1) Locate your device: > > > > usbconfig > > > > 2) Set config 1 > > > > usbconfig -d X.Y set_config 1 > > > > To permanently do this, you can set the configuration index 1 quirk for > > your device. > > I tried editing if_cdce.c adding to the static array mentioned in my > first mail: > > {USB_VPI(USB_VENDOR_TI, 0x6060, 0)}, > > obviously if this edit is necessary, a nice good little #define for > 0x6060 should be added where appropriate. > > The device get detected and properly claimed by the cdce module. > It is all good unless I actually try to connect with: > dhclient ue0 > > When I try this, the DHCP request just hangs and times out. > > I tried usbconfig -d 0.2 set_config 1 > This produces: > > cdce0: at uhub0, port 3, addr 2 (disconnected) > cdce0: on usbus0 > ue0: on cdce0 > ue0: Ethernet address: 00:e1:a7:76:76:81 > cdce1: on usbus0 > cdce1: No valid alternate setting found > device_attach: cdce1 attach returned 6 > cdce1: on usbus0 > cdce1: No valid alternate setting found > device_attach: cdce1 attach returned 6 > > Despite this moltitude of scary messages, dhclient now works good and I > can surf with my USB modem on FreeBSD, which is as awesome as it sounds. > Hi, > So, the questions now are: > 1) was the if_cdce.c edit necessary, or the usbconfig is more than > enough? The usbconfig is more than enough. > 2) how/should could this stuff be made in an automagic way by FreeBSD? > Since everything I have on this desktop has been detected flawlessly, > this was the only thing that made me suffer. The easiest way would be to create a devd config file: cat << EOF > /usr/local/etc/devd/myusbdevice.conf notify 100 { match "system" "USB"; match "subsystem" "DEVICE"; match "type" "ATTACH"; match "vendor" "0x0000"; match "product" "0x0000"; action "usbconfig -d $cdev set_config 1" }; EOF /etc/rc.d/devd restart The "vendor" is idVendor and "product" is idProduct. See output from this command: usbconfig -d X.Y dump_device_desc --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 16:00:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778B51065670 for ; Thu, 8 Dec 2011 16:00:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 07F568FC12 for ; Thu, 8 Dec 2011 16:00:56 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 39950124; Thu, 08 Dec 2011 16:59:49 +0100 From: Hans Petter Selasky To: Lorenzo Cogotti Date: Thu, 8 Dec 2011 16:57:16 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112081657.16048.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: USB Texas Instruments CDCE modem not recognized by cdce X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 16:00:57 -0000 On Thursday 08 December 2011 16:54:40 Lorenzo Cogotti wrote: > Eventually, should I send a patch to someone so that I am not the only > one to benefit from your help? If you want this quirk permanently you could try to add an entry to: /sys/dev/usb/quirk/usb_quirk.c You should use the quirk: UQ_CFG_INDEX_1 --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 17:53:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4902106564A; Thu, 8 Dec 2011 17:53:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id 944268FC0C; Thu, 8 Dec 2011 17:53:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LVW008189LEY900@smtpauth2.wiscmail.wisc.edu>; Thu, 08 Dec 2011 10:53:38 -0600 (CST) Received: from anacreon.physics.wisc.edu (anacreon.physics.wisc.edu [128.104.160.176]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LVW006RG9L9BI00@smtpauth2.wiscmail.wisc.edu>; Thu, 08 Dec 2011 10:53:33 -0600 (CST) Date: Thu, 08 Dec 2011 10:53:32 -0600 From: Nathan Whitehorn In-reply-to: <20111208090159.GA1924@cq1> To: Piotr Nowak Message-id: <4EE0EB8C.7050800@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.160.176 X-Spam-PmxInfo: Server=avs-9, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.8.164215, SenderIP=128.104.160.176 References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> User-Agent: Mozilla/5.0 (X11; U; FreeBSD powerpc; en-US; rv:1.9.2.22) Gecko/20110913 Thunderbird/3.1.14 Cc: Rafal Jaworowski , Gleb Kurtsou , mdf@freebsd.org, Arnaud Lacombe , freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 17:53:39 -0000 On 12/08/11 03:01, Piotr Nowak wrote: > We're working on PowerPC target using GCC 4.2.1 > and FreeBSD 6.1. It seems like we have similar > problem. In our case GCC sometimes very unfortunately > optimize code with -fno-omit-frame-pointer. > > Example shown below covers file sys/powerc/booke/pmap.c > and function pmap_kenter. If we disassemble kernel binary > we have: > > c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> > c0199990: 81 61 00 00 lwz r11,0(r1) > c0199994: 80 0b 00 04 lwz r0,4(r11) > c0199998: 7d 61 5b 78 mr r1,r11 > c019999c: 82 ab ff d4 lwz r21,-44(r11) > c01999a0: 7c 08 03 a6 mtlr r0 > c01999a4: 82 cb ff d8 lwz r22,-40(r11) > c01999a8: 82 eb ff dc lwz r23,-36(r11) > c01999ac: 83 0b ff e0 lwz r24,-32(r11) > c01999b0: 83 2b ff e4 lwz r25,-28(r11) > c01999b4: 83 4b ff e8 lwz r26,-24(r11) > c01999b8: 83 6b ff ec lwz r27,-20(r11) > > As you can see stack pointer on R1 is being updated > before stashed data were pulled off stack. (mr r1,r11) > As a result of this we have chance to get crash when > any interrupt hit shortly after stack pointer update. > The interrupt prologue will override not yet pulled off > pmap_kenter function data. > > The problem occures only with -fno-omit-frame-pointer > and not every branch returns are beeing corrupted. > > Do you think this issue may be somehow related to yours? > Are there any patches/solutions to fix it? Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 8 18:48:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 365D91065677 for ; Thu, 8 Dec 2011 18:48:15 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DEA448FC18 for ; Thu, 8 Dec 2011 18:48:14 +0000 (UTC) Received: by qabg14 with SMTP id g14so1964808qab.13 for ; Thu, 08 Dec 2011 10:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=vyxkBPYwCPm4bN2elkg4nm1L2+QuK6g9rT1/1IbIx70=; b=WXi2Gjjx/Zf0+1fyo8hezFbJhryRCnrmOFbxcEMDlLj6Pqnl7rqY2SQ2J63V6Jo/uM E8zbyDbDsv5BT9cri5chr2OejIKWnRbNSbS0Dxyp8bBJvFOPGL6OkEyxhqWp8Acib5nw 9AEGNDGHr1UTWMreFbbiPRI0pfvIy7MCSAe6w= Received: by 10.224.40.10 with SMTP id i10mr4154381qae.82.1323370094182; Thu, 08 Dec 2011 10:48:14 -0800 (PST) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id j7sm11447817qaq.11.2011.12.08.10.48.12 (version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 10:48:12 -0800 (PST) Date: Thu, 8 Dec 2011 13:48:04 -0500 From: Alexander Kabaev To: Gleb Kurtsou Message-ID: <20111208134804.125d45a9@kan.dyndns.org> In-Reply-To: <20111119100150.GA1560@reks> References: <20111119100150.GA1560@reks> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/b8ycDU4=DG=WkJhmifOR5S4"; protocol="application/pgp-signature" Cc: freebsd-hackers@FreeBSD.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:48:15 -0000 --Sig_/b8ycDU4=DG=WkJhmifOR5S4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 19 Nov 2011 12:01:50 +0200 Gleb Kurtsou wrote: > Hi, >=20 > I was lucky to write a bit of code which gcc 4.2 fails to compile > correctly with -O2. Too keep long story short the code fails for gcc > from base system and last gcc 4.2 snapshot from ports. It works with > gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. > -O and -Os optimization levels are fine (I've tried with all -f* flags > mentioned in documentation) >=20 > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > presume i386 should be fine. These options are also used for > compilation of kernel (with debugging enabled) and modules. >=20 > I'm not able to share the code, but have a test case reproducing the > bug. I've encountered the issue over a week ago and tried narrowing > it down to a simple test I could share but without much success. >=20 > The code itself is very common: initialize two structs on stack, call > a function with pointers to those stucts as arguments. A number of > inlined assertion functions. gcc fails to correctly optimize struct > assignments with -fno-omit-frame-pointer, I have a number of small > structs assigned, gcc decides not to use data coping but to assign > fields directly. I've tried disabling sra, tweaking sra parameters -- > no luck in forcing it to copy data. Replacing one particular > assignment with memcpy produces correct code, but that's not a > solution. >=20 > -O2 -fno-omit-frame-pointer -fno-inline is buggy > -O2 -fno-omit-frame-pointer -frename-registers is buggy >=20 > I found similar issue with gcc 4.6, but I'm not able to reproduce it > with gcc test case: > https://bugzilla.redhat.com/show_bug.cgi?id=3D679924 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47893 >=20 > I'll be glad to help debugging it and will be hanging on #bsddev > during weekend as glk. >=20 >=20 > Thanks, > Gleb. > _______________________________________________ It should take about ten times less time than this thread took already to isolate _short_ test case demonstrating the problem, yet nothing of the sort has shown up yet from anyone involved. Am I missing something? =20 --=20 Alexander Kabaev --Sig_/b8ycDU4=DG=WkJhmifOR5S4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFO4QZqQ6z1jMm+XZYRAmjnAJ44tsd9HP911WdQKLpgeKFlY1ESHgCfX19F walqkaEbywO7ZhK3fXIbkNo= =79Kx -----END PGP SIGNATURE----- --Sig_/b8ycDU4=DG=WkJhmifOR5S4-- From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 15:15:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 273B0106566B; Fri, 9 Dec 2011 15:15:14 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id C743E8FC08; Fri, 9 Dec 2011 15:15:13 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 47949EC333; Fri, 9 Dec 2011 16:15:12 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id MEDU-5MXR1NL; Fri, 9 Dec 2011 16:15:11 +0100 (CET) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id 4B74DEC330; Fri, 9 Dec 2011 16:15:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <4EE0EB8C.7050800@freebsd.org> Date: Fri, 9 Dec 2011 16:15:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Piotr Nowak , Arnaud Lacombe , mdf@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:15:14 -0000 On 2011-12-08, at 17:53, Nathan Whitehorn wrote: > On 12/08/11 03:01, Piotr Nowak wrote: >> We're working on PowerPC target using GCC 4.2.1 >> and FreeBSD 6.1. It seems like we have similar >> problem. In our case GCC sometimes very unfortunately >> optimize code with -fno-omit-frame-pointer. >>=20 >> Example shown below covers file sys/powerc/booke/pmap.c >> and function pmap_kenter. If we disassemble kernel binary >> we have: >>=20 >> c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> >> c0199990: 81 61 00 00 lwz r11,0(r1) >> c0199994: 80 0b 00 04 lwz r0,4(r11) >> c0199998: 7d 61 5b 78 mr r1,r11 >> c019999c: 82 ab ff d4 lwz r21,-44(r11) >> c01999a0: 7c 08 03 a6 mtlr r0 >> c01999a4: 82 cb ff d8 lwz r22,-40(r11) >> c01999a8: 82 eb ff dc lwz r23,-36(r11) >> c01999ac: 83 0b ff e0 lwz r24,-32(r11) >> c01999b0: 83 2b ff e4 lwz r25,-28(r11) >> c01999b4: 83 4b ff e8 lwz r26,-24(r11) >> c01999b8: 83 6b ff ec lwz r27,-20(r11) >>=20 >> As you can see stack pointer on R1 is being updated >> before stashed data were pulled off stack. (mr r1,r11) >> As a result of this we have chance to get crash when >> any interrupt hit shortly after stack pointer update. >> The interrupt prologue will override not yet pulled off >> pmap_kenter function data. >>=20 >> The problem occures only with -fno-omit-frame-pointer >> and not every branch returns are beeing corrupted. >>=20 >> Do you think this issue may be somehow related to yours? >> Are there any patches/solutions to fix it? >=20 > Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's = enabled in default kernel builds. I think that's a good idea. Even though we have managed to trigger this = only in rare cases, the problem is real and the code generated is broken = i.e. leads to corruption and panics. Rafal From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 15:48:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E202106564A for ; Fri, 9 Dec 2011 15:48:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 555BF8FC17 for ; Fri, 9 Dec 2011 15:48:29 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id E7EB246B0D; Fri, 9 Dec 2011 10:48:28 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 78725B95F; Fri, 9 Dec 2011 10:48:28 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 9 Dec 2011 09:45:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <11076.1322906459@critter.freebsd.dk> <0011FD6A-E29D-4F67-913C-897BA1B2F56F@gmail.com> In-Reply-To: <0011FD6A-E29D-4F67-913C-897BA1B2F56F@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112090945.56414.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Dec 2011 10:48:28 -0500 (EST) Cc: Filippo Sironi , Poul-Henning Kamp Subject: Re: mmap implementation for cdev X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:48:29 -0000 On Saturday, December 03, 2011 5:37:01 am Filippo Sironi wrote: > I need to access the memory both from user space and kernel space, I cannot do that (simply) with an mmap or thread-specific storage if I recall correctly. You could allocate a dedicated VM object for each thread's information and populate it with a single page. You could then return that from a csw->d_mmap_single() routine. You could also use some routines I'm about to add for the shm_open() API that let you easily map shm_open() objects into the kernel where threads create a shm object in userland and pass the fd into the kernel to let the kernel map it. > On 03/dic/2011, at 11.00, Poul-Henning Kamp wrote: > > > In message , Filippo Sironi wri > > tes: > > > > Why don't you just use mmap(2) ? I couldn't see anything you > > couldn't do with it. > > > > There's also support in pthread for thread specific storage, which > > should be your first choice. > > > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 17:49:58 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE521065676; Fri, 9 Dec 2011 17:49:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1288D8FC14; Fri, 9 Dec 2011 17:49:57 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so6045331wgb.31 for ; Fri, 09 Dec 2011 09:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=10XqQNsdfhwg6N4rZ9G4ocnsp+jPm12xB4rPdQ3qxqk=; b=RkHAyk08MHEHr1VJifgThBMNP4uJMwsROXq+KIkWPQyJV7BUl0HFbQQSasKJ+IZWdP d34kLtuAPjqgdby0uczdJh8LROuBUR7+F613ODGUde7ckroutIvlO6ewyG1S4nQeMYaj CNJnq3cgu6hYoNMTKc0nZVY3DRc347mKDeOC8= MIME-Version: 1.0 Received: by 10.216.49.1 with SMTP id w1mr324610web.29.1323452997074; Fri, 09 Dec 2011 09:49:57 -0800 (PST) Received: by 10.180.94.2 with HTTP; Fri, 9 Dec 2011 09:49:57 -0800 (PST) In-Reply-To: <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> Date: Fri, 9 Dec 2011 12:49:57 -0500 Message-ID: From: Arnaud Lacombe To: Rafal Jaworowski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Gleb Kurtsou , Nathan Whitehorn , mdf@freebsd.org, Piotr Nowak Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 17:49:59 -0000 Hi, On Fri, Dec 9, 2011 at 10:15 AM, Rafal Jaworowski wrote: > > On 2011-12-08, at 17:53, Nathan Whitehorn wrote: > >> On 12/08/11 03:01, Piotr Nowak wrote: >>> We're working on PowerPC target using GCC 4.2.1 >>> and FreeBSD 6.1. It seems like we have similar >>> problem. In our case GCC sometimes very unfortunately >>> optimize code with -fno-omit-frame-pointer. >>> >>> Example shown below covers file sys/powerc/booke/pmap.c >>> and function pmap_kenter. If we disassemble kernel binary >>> we have: >>> >>> c019998c: =A0 4b ec 6a ed =A0 =A0 bl =A0 =A0 =A0c0060478<_mtx_unlock_sp= in_flags> >>> c0199990: =A0 81 61 00 00 =A0 =A0 lwz =A0 =A0 r11,0(r1) >>> c0199994: =A0 80 0b 00 04 =A0 =A0 lwz =A0 =A0 r0,4(r11) >>> c0199998: =A0 7d 61 5b 78 =A0 =A0 mr =A0 =A0 =A0r1,r11 >>> c019999c: =A0 82 ab ff d4 =A0 =A0 lwz =A0 =A0 r21,-44(r11) >>> c01999a0: =A0 7c 08 03 a6 =A0 =A0 mtlr =A0 =A0r0 >>> c01999a4: =A0 82 cb ff d8 =A0 =A0 lwz =A0 =A0 r22,-40(r11) >>> c01999a8: =A0 82 eb ff dc =A0 =A0 lwz =A0 =A0 r23,-36(r11) >>> c01999ac: =A0 83 0b ff e0 =A0 =A0 lwz =A0 =A0 r24,-32(r11) >>> c01999b0: =A0 83 2b ff e4 =A0 =A0 lwz =A0 =A0 r25,-28(r11) >>> c01999b4: =A0 83 4b ff e8 =A0 =A0 lwz =A0 =A0 r26,-24(r11) >>> c01999b8: =A0 83 6b ff ec =A0 =A0 lwz =A0 =A0 r27,-20(r11) >>> >>> As you can see stack pointer on R1 is being updated >>> before stashed data were pulled off stack. (mr r1,r11) >>> As a result of this we have chance to get crash when >>> any interrupt hit shortly after stack pointer update. >>> The interrupt prologue will override not yet pulled off >>> pmap_kenter function data. >>> >>> The problem occures only with -fno-omit-frame-pointer >>> and not every branch returns are beeing corrupted. >>> >>> Do you think this issue may be somehow related to yours? >>> Are there any patches/solutions to fix it? >> >> Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabl= ed in default kernel builds. > > I think that's a good idea. Even though we have managed to trigger this o= nly in rare cases, the problem is real and the code generated is broken i.e= . leads to corruption and panics. > How can you make any conclusion without having seen a single line of code actually triggering the problem ? That sounds very irresponsible... - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 18:15:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0E3F106564A; Fri, 9 Dec 2011 18:15:50 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F8D88FC0C; Fri, 9 Dec 2011 18:15:49 +0000 (UTC) Received: by lahl5 with SMTP id l5so835047lah.13 for ; Fri, 09 Dec 2011 10:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HHC+wDFRxZrtoW2EXfqTtFplqQIqFFA+QpjPkWk5zPM=; b=HJQcM8L3GeE7zWqb5gGMXhb33MzONX7w01rkdcTMfx/2AVYHWe4QAqIIzQ7c9cJjzw LwAVijAnNScjyN6QPVEjOuewuKezdR0tBHCxJ6yrz04beG4/SJ+ZK8bpmsEC9r4je6k2 ReYjb9C3FELKS9/a6rm9yb5S1qtyF2t2940Xo= Received: by 10.152.110.130 with SMTP id ia2mr5619315lab.26.1323454548791; Fri, 09 Dec 2011 10:15:48 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id xx14sm8363416lab.17.2011.12.09.10.15.47 (version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 10:15:47 -0800 (PST) Date: Fri, 9 Dec 2011 20:15:50 +0200 From: Gleb Kurtsou To: Rafal Jaworowski Message-ID: <20111209181550.GA3555@reks> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, mdf@freebsd.org, Nathan Whitehorn , Arnaud Lacombe , Piotr Nowak Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:15:51 -0000 On (09/12/2011 16:15), Rafal Jaworowski wrote: > > On 2011-12-08, at 17:53, Nathan Whitehorn wrote: > > > On 12/08/11 03:01, Piotr Nowak wrote: > >> We're working on PowerPC target using GCC 4.2.1 > >> and FreeBSD 6.1. It seems like we have similar > >> problem. In our case GCC sometimes very unfortunately > >> optimize code with -fno-omit-frame-pointer. > >> > >> Example shown below covers file sys/powerc/booke/pmap.c > >> and function pmap_kenter. If we disassemble kernel binary > >> we have: > >> > >> c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> > >> c0199990: 81 61 00 00 lwz r11,0(r1) > >> c0199994: 80 0b 00 04 lwz r0,4(r11) > >> c0199998: 7d 61 5b 78 mr r1,r11 > >> c019999c: 82 ab ff d4 lwz r21,-44(r11) > >> c01999a0: 7c 08 03 a6 mtlr r0 > >> c01999a4: 82 cb ff d8 lwz r22,-40(r11) > >> c01999a8: 82 eb ff dc lwz r23,-36(r11) > >> c01999ac: 83 0b ff e0 lwz r24,-32(r11) > >> c01999b0: 83 2b ff e4 lwz r25,-28(r11) > >> c01999b4: 83 4b ff e8 lwz r26,-24(r11) > >> c01999b8: 83 6b ff ec lwz r27,-20(r11) > >> > >> As you can see stack pointer on R1 is being updated > >> before stashed data were pulled off stack. (mr r1,r11) > >> As a result of this we have chance to get crash when > >> any interrupt hit shortly after stack pointer update. > >> The interrupt prologue will override not yet pulled off > >> pmap_kenter function data. > >> > >> The problem occures only with -fno-omit-frame-pointer > >> and not every branch returns are beeing corrupted. > >> > >> Do you think this issue may be somehow related to yours? > >> Are there any patches/solutions to fix it? > > > > Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. > > I think that's a good idea. Even though we have managed to trigger > this only in rare cases, the problem is real and the code generated is > broken i.e. leads to corruption and panics. -fno-omit-frame-pointer is there for kernel debugger to be able to generate backtraces. Hacking long abandoned gcc version won't get us far either. IMO we'd better concentrate on external toolchain support and clang. I wasn't able to come up with a small test case for the problem month ago, I'll try again once I have free time. > > Rafal > From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 18:45:13 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32C22106566B for ; Fri, 9 Dec 2011 18:45:13 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B15038FC08 for ; Fri, 9 Dec 2011 18:45:12 +0000 (UTC) Received: by qcse13 with SMTP id e13so3569920qcs.13 for ; Fri, 09 Dec 2011 10:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ohG0q/c6mbyQItfAbPTH3UM/iHSuDyF9ed29PlaOwA0=; b=cAXIgR1IpJhHrX4c9tcA/4xULjt5H4IzfEMQfWziEJUEeVT93qqUlmtBhxA36BKbhw YvPHD3msCIZtSFeKXA2gQCh5WkJH7cjbLBncnE/oGtaDg9vJXdHuOsEAPvJ9c47GH80j CkdpSMpkmIjikg32i7XytuikZk9wGsSt1irGI= MIME-Version: 1.0 Received: by 10.50.217.195 with SMTP id pa3mr4955542igc.12.1323456311790; Fri, 09 Dec 2011 10:45:11 -0800 (PST) Received: by 10.231.199.18 with HTTP; Fri, 9 Dec 2011 10:45:11 -0800 (PST) Received: by 10.231.199.18 with HTTP; Fri, 9 Dec 2011 10:45:11 -0800 (PST) In-Reply-To: References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> Date: Fri, 9 Dec 2011 18:45:11 +0000 Message-ID: From: Chris Rees To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mdf@freebsd.org, Gleb Kurtsou , freebsd-hackers@freebsd.org, Piotr Nowak , Rafal Jaworowski , Nathan Whitehorn Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:45:13 -0000 On 9 Dec 2011 17:51, "Arnaud Lacombe" wrote: > > Hi, > > On Fri, Dec 9, 2011 at 10:15 AM, Rafal Jaworowski wrote: > > > > On 2011-12-08, at 17:53, Nathan Whitehorn wrote: > > > >> On 12/08/11 03:01, Piotr Nowak wrote: > >>> We're working on PowerPC target using GCC 4.2.1 > >>> and FreeBSD 6.1. It seems like we have similar > >>> problem. In our case GCC sometimes very unfortunately > >>> optimize code with -fno-omit-frame-pointer. > >>> > >>> Example shown below covers file sys/powerc/booke/pmap.c > >>> and function pmap_kenter. If we disassemble kernel binary > >>> we have: > >>> > >>> c019998c: 4b ec 6a ed bl c0060478<_mtx_unlock_spin_flags> > >>> c0199990: 81 61 00 00 lwz r11,0(r1) > >>> c0199994: 80 0b 00 04 lwz r0,4(r11) > >>> c0199998: 7d 61 5b 78 mr r1,r11 > >>> c019999c: 82 ab ff d4 lwz r21,-44(r11) > >>> c01999a0: 7c 08 03 a6 mtlr r0 > >>> c01999a4: 82 cb ff d8 lwz r22,-40(r11) > >>> c01999a8: 82 eb ff dc lwz r23,-36(r11) > >>> c01999ac: 83 0b ff e0 lwz r24,-32(r11) > >>> c01999b0: 83 2b ff e4 lwz r25,-28(r11) > >>> c01999b4: 83 4b ff e8 lwz r26,-24(r11) > >>> c01999b8: 83 6b ff ec lwz r27,-20(r11) > >>> > >>> As you can see stack pointer on R1 is being updated > >>> before stashed data were pulled off stack. (mr r1,r11) > >>> As a result of this we have chance to get crash when > >>> any interrupt hit shortly after stack pointer update. > >>> The interrupt prologue will override not yet pulled off > >>> pmap_kenter function data. > >>> > >>> The problem occures only with -fno-omit-frame-pointer > >>> and not every branch returns are beeing corrupted. > >>> > >>> Do you think this issue may be somehow related to yours? > >>> Are there any patches/solutions to fix it? > >> > >> Should we turn off -fno-omit-frame-frame-pointer on PPC then? It's enabled in default kernel builds. > > > > I think that's a good idea. Even though we have managed to trigger this only in rare cases, the problem is real and the code generated is broken i.e. leads to corruption and panics. > > > How can you make any conclusion without having seen a single line of > code actually triggering the problem ? That sounds very > irresponsible... > However, if he's right it's very clever. Chris From owner-freebsd-hackers@FreeBSD.ORG Fri Dec 9 20:10:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06F52106564A for ; Fri, 9 Dec 2011 20:10:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4448FC17 for ; Fri, 9 Dec 2011 20:10:39 +0000 (UTC) Received: by wgbdr11 with SMTP id dr11so6264073wgb.31 for ; Fri, 09 Dec 2011 12:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y6CX8bcTBCpIgKVJxD+ki/vvouel9QPYmfeOpj48JJU=; b=B5MvGR9dz9uABcKwUJjDyiSH+3NL2rGvyq1ScsSNb/dODqSiyTV+bgU6+Mf6g+Krmh mcJF4SkIGpAfQgdjhzS1JPEGV8fVbCVbYMK8EzFNUDvKIBIoH2lCZj4cpUsdx/Tysy3t 9Nn76GYlgljWFKo2gNK8GstaiWRlTMGYJ8/Fk= MIME-Version: 1.0 Received: by 10.227.208.13 with SMTP id ga13mr9024968wbb.4.1323461438339; Fri, 09 Dec 2011 12:10:38 -0800 (PST) Received: by 10.180.101.102 with HTTP; Fri, 9 Dec 2011 12:10:38 -0800 (PST) In-Reply-To: <20111209181550.GA3555@reks> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> <20111209181550.GA3555@reks> Date: Fri, 9 Dec 2011 15:10:38 -0500 Message-ID: From: Ryan Stone To: Gleb Kurtsou Content-Type: text/plain; charset=ISO-8859-1 Cc: mdf@freebsd.org, freebsd-hackers@freebsd.org, Piotr Nowak , Rafal Jaworowski , Nathan Whitehorn , Arnaud Lacombe Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:10:40 -0000 On Fri, Dec 9, 2011 at 1:15 PM, Gleb Kurtsou wrote: > -fno-omit-frame-pointer is there for kernel debugger to be able to > generate backtraces. It's also needed by the DTrace stack() action, hwpmc callchain capture and stack(9). Disabling it as anything other than a very short-term bandaid is a non-starter. From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 10 01:21:25 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1D341065670; Sat, 10 Dec 2011 01:21:25 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A10238FC15; Sat, 10 Dec 2011 01:21:24 +0000 (UTC) Received: by lahl5 with SMTP id l5so986563lah.13 for ; Fri, 09 Dec 2011 17:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Hut5+F1QZ0FNxjwo8O1wEFY6+7iPqcf93uEk/we2szc=; b=LDY1lZFXdrQupwqPXbuFbvyekiOE70g+m3DxjBhcdPqb9eaJfibobUO9pedtNxb4Xi zOFosxzvILiBVQFHUGB43Lutt/hTdKuhiICcNuIqv8QRwUKC1fdjQ+pBRe2ASYVql7tA UzXkblTxGFlu0VQRBlPKk+Yh/axCRlT9pHDJ4= Received: by 10.152.104.167 with SMTP id gf7mr6221109lab.46.1323480083473; Fri, 09 Dec 2011 17:21:23 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id mo6sm9227264lab.11.2011.12.09.17.21.21 (version=SSLv3 cipher=OTHER); Fri, 09 Dec 2011 17:21:22 -0800 (PST) Date: Sat, 10 Dec 2011 03:21:24 +0200 From: Gleb Kurtsou To: Ryan Stone Message-ID: <20111210012124.GA95149@reks> References: <20111119100150.GA1560@reks> <20111208090159.GA1924@cq1> <4EE0EB8C.7050800@freebsd.org> <6D023449-EDEA-4B1C-975D-54AA2F4328CE@semihalf.com> <20111209181550.GA3555@reks> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mdf@freebsd.org, freebsd-hackers@freebsd.org, Piotr Nowak , Rafal Jaworowski , Nathan Whitehorn , Arnaud Lacombe Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 01:21:25 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Please find test case and test results attached. (gcc-test1.shar.txt) The long story short: only gcc-4.2 is affected, gcc 3.4, 4.4 and 4.6 are ok. clang is ok. (test-cc.txt) Nearly all of the workarounds I used in original test doesn't work in this test case (see #ifdef BAD_FIX in sources). gcc 4.2 fails even with -O1, it has nothing to do with -fno-omit-frame-pointer, finline-functions, etc. (test-cflags.txt) Compile with -DFIX1 to work around problem (replace struct assignment with memcpy): % make test XFLAGS="-O2 -DFIX1" rm -f gcc-test1 src1.o src2.o src3.o cc -O2 -DFIX1 -g -std=gnu99 -c src1.c cc -O2 -DFIX1 -g -std=gnu99 -c src2.c cc -O2 -DFIX1 -g -std=gnu99 -c src3.c cc -O2 -DFIX1 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok Happy hacking! --FCuugMFkClbJLl1L Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="gcc-test1.shar.txt" # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # Makefile # array.h # debug.h # hdr1.h # src1.c # src2.c # src3.c # echo x - Makefile sed 's/^X//' >Makefile << 'b67911656ef5d18c4ae36cb6741b7965' XPROG= gcc-test1 XSRCS= src1.c src2.c src3.c hdr1.h XNO_MAN= X XXFLAGS?=-O2 -fno-omit-frame-pointer X X#WARNS=6 X#NO_WERROR= X XSSP_CFLAGS= XDEBUG_FLAGS= -g XCSTD= gnu99 X XCFLAGS= ${XFLAGS} X X.PHONY: test Xtest: clean ${PROG} X ${.OBJDIR}/${PROG} X X.include b67911656ef5d18c4ae36cb6741b7965 echo x - array.h sed 's/^X//' >array.h << '3ff8e27b821109f0551768c5e1b6bc0d' X#include "debug.h" X X#define ARRAY_HEAD(name, type, capacity) \ X struct name { \ X size_t arr_count; \ X struct type arr_items[capacity]; \ X } X X#define ARRAY_INIT(head) do { \ X (head)->arr_count = 0; \ X} while (0) X X#define ARRAY_CAPACITY(head) \ X (sizeof((head)->arr_items) / sizeof((head)->arr_items[0])) X X#define ARRAY_COUNT(head) (head)->arr_count X X#ifdef FIX1 X X#define ARRAY_INSERT_TAIL(head, elm) do { \ X ASSERT(ARRAY_COUNT((head)) < ARRAY_CAPACITY((head))); \ X memcpy(&(head)->arr_items[(head)->arr_count++], &(elm), sizeof(elm)); \ X} while (0) X X#else X X#define ARRAY_INSERT_TAIL(head, elm) do { \ X ASSERT(ARRAY_COUNT((head)) < ARRAY_CAPACITY((head))); \ X (head)->arr_items[(head)->arr_count++] = (elm); \ X} while (0) X X#endif X X#define ARRAY_FOREACH(var, head) \ X for ((var) = &(head)->arr_items[0]; \ X (var) < &(head)->arr_items[0] + (head)->arr_count; \ X (var)++) 3ff8e27b821109f0551768c5e1b6bc0d echo x - debug.h sed 's/^X//' >debug.h << '0483bb2079adc3936e07b79b224930aa' X#ifndef XXX_DEBUG_H X#define XXX_DEBUG_H X X#include X X#define ASSERT(cond) \ X (__predict_false(cond) ? (void)0 : \ X debug_assert(#cond, __FILE__, __LINE__, __func__)) X Xvoid debug_assert(const char *msg, const char *file, int line, X const char *func); X X#endif 0483bb2079adc3936e07b79b224930aa echo x - hdr1.h sed 's/^X//' >hdr1.h << '023696bd679b9970bb745000978348c8' X#include X X#include "array.h" X#include "debug.h" X Xtypedef union { X struct { X bool flag1:1; X bool flag2:1; X bool flag3:1; X bool flag4:1; X bool flag5:1; X bool flag6:1; X bool flag7:1; X bool flag8:1; X bool flag9:1; X bool flag10:1; X }; X uint32_t bits; X} xflags_t; X Xstruct session { X xflags_t flags; X struct sockaddr_in addr; X}; X Xstruct dummy1 { X int a, b, c; X void *ptr; X}; X XARRAY_HEAD(addr_list, sockaddr_in, 2); X Xstruct addr_list; X Xvoid test_fail(void *arg1, void *arg2, X void *arg3, const void *arg4, X const struct addr_list *addr_list, X const void *arg5); X Xbool test_run(struct session *sess); 023696bd679b9970bb745000978348c8 echo x - src1.c sed 's/^X//' >src1.c << 'd76eceed15fcbc6c2cf5da795270acb3' X#include X#include X#include X X#include X#include X#include X X#include "hdr1.h" X Xstatic void test_set_dummy(struct dummy1 *arg1, void *arg2); X Xbool Xtest_run(struct session *sess) X{ X struct dummy1 d1 __unused; X struct addr_list tmp_addr_list; X struct sockaddr_in tmp_addr; X bool rv = true; X X#ifdef BAD_FIX X // Removing assertions fixes original test case X ASSERT(sess->flags.flag5); X ASSERT(sess->flags.flag4); X ASSERT(sess->flags.flag7); X ASSERT(sess->flags.flag9); X#endif X X // Replacing assignment with memcpy fixes original test case X tmp_addr = sess->addr; X tmp_addr.sin_port = 0; X ARRAY_INIT(&tmp_addr_list); X ARRAY_INSERT_TAIL(&tmp_addr_list, tmp_addr); X X#ifdef BAD_FIX X // Removing function call fixes original test case X test_set_dummy(&d1, sess); X#endif X X test_fail(NULL, NULL, X NULL, NULL, &tmp_addr_list, NULL); X X return rv; X} X Xstruct dummy1 d1_template = { X .a = 1, X .b = 2, X}; X Xstatic void Xtest_set_dummy(struct dummy1 *arg1, void *arg2 __unused) X{ X *arg1 = d1_template; X} d76eceed15fcbc6c2cf5da795270acb3 echo x - src2.c sed 's/^X//' >src2.c << '84fb2eee7bfbf3aefc26348a2ac4dc34' X#include X#include X#include X X#include "hdr1.h" X Xvoid Xtest_fail(void *arg1 __unused, void *arg2 __unused, X void *arg3 __unused, const void *arg4 __unused, X const struct addr_list *addr_list, X const void *arg6 __unused) X{ X const struct sockaddr_in *addr; X X ARRAY_FOREACH(addr, addr_list) { X ASSERT(addr->sin_addr.s_addr == ntohl(INADDR_ANY)); X } X} 84fb2eee7bfbf3aefc26348a2ac4dc34 echo x - src3.c sed 's/^X//' >src3.c << 'e773224103ed63e54dbf72915ff448a8' X#include X#include X#include X X#include X#include X#include X X#include "hdr1.h" X Xint Xmain(int argc __unused, char **argv __unused) X{ X struct session *sess; X X sess = calloc(sizeof(*sess), 1); X sess->flags.flag1 = true; X sess->flags.flag4 = true; X sess->flags.flag5 = true; X sess->flags.flag6 = true; X sess->flags.flag7 = true; X sess->flags.flag9 = true; X X sess->addr.sin_addr.s_addr = ntohl(INADDR_ANY); X X test_run(sess); X X puts("ok"); X X return 0; X} X Xvoid Xdebug_assert(const char *msg, const char *file, int line, const char *func) X{ X if (func == NULL) X fprintf(stderr, "%s:%d: Assertion failed: %s\n", X file, line, msg); X else X fprintf(stderr, "%s:%d:%s: Assertion failed: %s\n", X file, line, func, msg); X abort(); X} e773224103ed63e54dbf72915ff448a8 exit --FCuugMFkClbJLl1L Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="test-cc.txt" % for CC in cc gcc42 gcc34 gcc44 gcc46 clang; do ${CC} -v; make test CC=${CC}; done Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] rm -f gcc-test1 src1.o src2.o src3.o cc -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c cc -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c cc -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c cc -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) *** Signal 6 Stop in /home/gleb/projects/gcc-test1. zsh: exit 1 make test CC=${CC} Using built-in specs. Target: x86_64-portbld-freebsd9.0 Configured with: ./../gcc-4.2-20090325/configure --disable-nls --libdir=/usr/local/lib/gcc42 --libexecdir=/usr/local/libexec/gcc42 --program-suffix=42 --with-as=/usr/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc42/include/c++/ --with-ld=/usr/bin/ld --with-libiconv-prefix=/usr/local --with-system-zlib --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc42 x86_64-portbld-freebsd9.0 Thread model: posix gcc version 4.2.5 20090325 (prerelease) [FreeBSD Ports Collection] rm -f gcc-test1 src1.o src2.o src3.o gcc42 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c gcc42 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c gcc42 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c gcc42 -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) *** Signal 6 Stop in /home/gleb/projects/gcc-test1. zsh: exit 1 make test CC=${CC} Reading specs from /usr/local/lib/gcc/x86_64-portbld-freebsd9.0/3.4.6/gcc/x86_64-portbld-freebsd9.0/3.4.6/specs Configured with: ./..//gcc-3.4.6/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=34 --libdir=/usr/local/lib/gcc/x86_64-portbld-freebsd9.0/3.4.6 --with-gxx-include-dir=/usr/local/lib/gcc/x86_64-portbld-freebsd9.0/3.4.6/include/c++/ --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc34 x86_64-portbld-freebsd9.0 Thread model: posix gcc version 3.4.6 [FreeBSD] rm -f gcc-test1 src1.o src2.o src3.o gcc34 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c gcc34 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c gcc34 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c gcc34 -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /usr/bin/ld: error in /usr/local/lib/gcc/x86_64-portbld-freebsd9.0/3.4.6/gcc/x86_64-portbld-freebsd9.0/3.4.6/crtend.o(.eh_frame); no .eh_frame_hdr table will be created. /home/gleb/projects/gcc-test1/gcc-test1 ok Using built-in specs. Target: x86_64-portbld-freebsd9.0 Configured with: ./../gcc-4.4-20111108/configure --disable-nls --enable-languages=c,c++,fortran --libdir=/usr/local/lib/gcc44 --libexecdir=/usr/local/libexec/gcc44 --program-suffix=44 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc44/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc44 --build=x86_64-portbld-freebsd9.0 Thread model: posix gcc version 4.4.7 20111108 (prerelease) (FreeBSD Ports Collection) rm -f gcc-test1 src1.o src2.o src3.o gcc44 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c gcc44 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c gcc44 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c gcc44 -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok Using built-in specs. COLLECT_GCC=gcc46 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.2/lto-wrapper Target: x86_64-portbld-freebsd9.0 Configured with: ./../gcc-4.6.2/configure --disable-nls --enable-languages=c,c++,fortran --libdir=/usr/local/lib/gcc46 --libexecdir=/usr/local/libexec/gcc46 --program-suffix=46 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc46/include/c++/ --with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --enable-languages=c,c++,fortran,java --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc46 --build=x86_64-portbld-freebsd9.0 Thread model: posix gcc version 4.6.2 (FreeBSD Ports Collection) rm -f gcc-test1 src1.o src2.o src3.o gcc46 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c gcc46 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c gcc46 -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c gcc46 -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok clang version 3.0 (trunk) Target: amd64-portbld-freebsd9.0 Thread model: posix rm -f gcc-test1 src1.o src2.o src3.o clang -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src1.c clang -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src2.c clang -O2 -fno-omit-frame-pointer -g -std=gnu99 -c src3.c clang -O2 -fno-omit-frame-pointer -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o clang: warning: argument unused during compilation: '-g' clang: warning: argument unused during compilation: '-std=gnu99' /home/gleb/projects/gcc-test1/gcc-test1 ok ~/projects/gcc-test1 % --FCuugMFkClbJLl1L Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="test-cflags.txt" % for XFLAGS in -O0 -O1 -O2 -O3; do make test XFLAGS=${XFLAGS}; done rm -f gcc-test1 src1.o src2.o src3.o cc -O0 -g -std=gnu99 -c src1.c cc -O0 -g -std=gnu99 -c src2.c cc -O0 -g -std=gnu99 -c src3.c cc -O0 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 ok rm -f gcc-test1 src1.o src2.o src3.o cc -O1 -g -std=gnu99 -c src1.c cc -O1 -g -std=gnu99 -c src2.c cc -O1 -g -std=gnu99 -c src3.c cc -O1 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) *** Signal 6 Stop in /home/gleb/projects/gcc-test1. zsh: exit 1 make test XFLAGS=${XFLAGS} rm -f gcc-test1 src1.o src2.o src3.o cc -O2 -g -std=gnu99 -c src1.c cc -O2 -g -std=gnu99 -c src2.c cc -O2 -g -std=gnu99 -c src3.c cc -O2 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) *** Signal 6 Stop in /home/gleb/projects/gcc-test1. zsh: exit 1 make test XFLAGS=${XFLAGS} rm -f gcc-test1 src1.o src2.o src3.o cc -O3 -g -std=gnu99 -c src1.c cc -O3 -g -std=gnu99 -c src2.c cc -O3 -g -std=gnu99 -c src3.c cc -O3 -g -std=gnu99 -o gcc-test1 src1.o src2.o src3.o /home/gleb/projects/gcc-test1/gcc-test1 src2.c:16:test_fail: Assertion failed: addr->sin_addr.s_addr == ntohl(INADDR_ANY) *** Signal 6 --FCuugMFkClbJLl1L-- From owner-freebsd-hackers@FreeBSD.ORG Sat Dec 10 10:54:59 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56B351065672 for ; Sat, 10 Dec 2011 10:54:59 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id D99718FC14 for ; Sat, 10 Dec 2011 10:54:58 +0000 (UTC) Received: by eaai12 with SMTP id i12so2536787eaa.13 for ; Sat, 10 Dec 2011 02:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=EYDJP2kQzPiQI0BX3x9VpJpMVqbB695frVpFFfMSPFE=; b=U3vYb1VIfuL16DUtFV2EBQ4BKQyV3pg6IrKYbTeY664341PvFtA5sDi0Gb1mMRhm4/ Xxov9iM5Qh5iggEqqu0WZIqeOZk153UcWGZ2JtPsAvkS+ub6CXbDzbwP66JuGRlhwZUp r9+31CVq4HS/sJUqztuMf7RUxhVxVIxPRYyxM= Received: by 10.213.9.148 with SMTP id l20mr1748057ebl.44.1323514497708; Sat, 10 Dec 2011 02:54:57 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id c9sm44022965eeb.0.2011.12.10.02.54.53 (version=SSLv3 cipher=OTHER); Sat, 10 Dec 2011 02:54:55 -0800 (PST) Message-ID: <20111210.105456.372.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sat, 10 Dec 2011 11:54:56 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: References: X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Re: CPUTYPE and friends, from 'make.conf' benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 10:54:59 -0000 My home server was also built with 'native' and it's unixbench score = was:=0D=0A231.3 (24.6 min)=0D=0A=0D=0A# /bin/sh -c "gcc -v -x c -E = -mtune=3Dnative /dev/null -o /dev/null 2>&1 | grep mtune | sed -e = 's/.*mtune=3D//'"=0D=0Aathlon-4=0D=0A=0D=0AHere it didn't return = 'generic'=0D=0A=0D=0AJust out of curiosity, I've removed 'native' and = left only 'CPUTYPE?=3Dathlon-xp'=0D=0AAfter rebuild of OS, it's unixbench = score is now:=0D=0A319.8 (22.4 min)=0D=0A=0D=0AThat is a 38.26%, global = speed gain!=0D=0ANow I'm 100% sure, 'native' should always be = avoided!=0D=0A=0D=0A=0D=0A> It is acceptable to set CPUTYPE and to append = certain flags to CFLAGS=0D=0A> in make.conf, and CPUTYPE is used in many = ports for=0D=0A> architecture-dependent build options.=0D=0A=0D=0ADefault = CFLAGS are are '-O2 -pipe'=0D=0AWhich are recommended and proven to be = safe?=0D=0A=0D=0A=0D=0A> The use of CPUTYPE usually has a relatively = modest affect on general=0D=0A> benchmarks in the base system, because a = lot of code there is=0D=0A> intentionally generic, and is compiled with = an older toolchain using=0D=0A> conservative flags, so aggressive = optimizations that can take fuller=0D=0A> advantage of CPU extensions are = not used.=0D=0A=0D=0AI believe because OS stability, is a top = priority.=0D=0A=0D=0A> However, CPUTYPE can have a dramatic affect on = certain applications=0D=0A> when used with appropriate compiler flags = (-O3, etc.), particularly=0D=0A> those in some ports.=0D=0A=0D=0ASo, = CPUTYPE is mainly for boosting performance of ported apps.=0D=0ARegarding = compiler flags (-O3, etc.) I use them, only if port offers = them.=0D=0A=0D=0A> =0D=0A> b.=0D=0A> =0D=0A=0D=0ADomagoj Smol=E8i=E6