From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 00:20:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1EF03D7 for ; Sun, 20 Jul 2014 00:20:12 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A083A2D02 for ; Sun, 20 Jul 2014 00:20:12 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rl12so5775966iec.15 for ; Sat, 19 Jul 2014 17:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=i6F5j/OIVN05qUCqi/2jnhcJ41/HAB0nf3Df4/VV21Q=; b=BdA65JkUJ8L0vNwktjEKrPF3sILjrgt1gAnn/7DhTDy+up0E+M2XH9+UmI+E45aRQ5 F1qEkb/7gcpX2/gZF0aRa/9eunwCA7YOTAOp4mU9OeSBXhPVIT/1qCkGI5YFbIOmLvPx +cslMvpzc9LqCACUtavfFN75S4SHYZgQBj8ZRspvgbOhGPI4zE71snXl3aLbO9XABjlk epFC0SzMsYsyEMugWnDBAE4NoqubWDWvTviQgL2q3k0bxxClG5VuFvGIX762olIHcSqW YdVepaTgzPngX/O+ZdRj42rJLcJd8exKjL4bXxEORw4lC6/SmMxE6SjykrcBEbugqyKp PPhg== X-Gm-Message-State: ALoCoQmkXr3tyV+qw2Y8S5UTyJK0PtsBFC8Fw3rGY7rtmKt9Zpzj3qM/y2DPL0Anf8Juorkw9zhb X-Received: by 10.50.41.68 with SMTP id d4mr56900895igl.43.1405815605549; Sat, 19 Jul 2014 17:20:05 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ka6sm22210466igb.8.2014.07.19.17.20.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 17:20:04 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Warner Losh In-Reply-To: <1402156516.20883.154.camel@revolution.hippie.lan> Date: Sat, 19 Jul 2014 18:20:04 -0600 Message-Id: <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> References: <1402156516.20883.154.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org, Olavi Kumpulainen X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 00:20:13 -0000 --Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 7, 2014, at 9:55 AM, Ian Lepore wrote: > On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >> Hi there, >>=20 >> If this question has been discussed before, sorry. I couldn=B4t find = anything when scanning through the archives though. >>=20 >> So, I=B4m running FreeBSD-10/stable on a RPI version B as you can see = here; >>=20 >>=20 >> Copyright (c) 1992-2014 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 >> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 >>=20 >>=20 >> I have this little program; >>=20 >> $ cat t.cc >>=20 >> #include >> #include >>=20 >> void func()=20 >> { >> throw std::exception(); >> } >>=20 >>=20 >> int main() >> { >> std::cout << "Starting throw-test" << std::endl; >>=20 >> try >> { >> func(); >> } >> catch(std::exception){ >> std::cout << =93In my exception handler" << std::endl; >> } >> catch(...) { >> std::cout << "In catch-all handler" << std::endl; >> } >>=20 >> return 0; >> } >>=20 >> With this Makefile; >>=20 >> $ cat Makefile >>=20 >> all : t >>=20 >> t : t.cc >> c++ -o t -fexceptions t.cc >>=20 >>=20 >> Running the above produces the following result; >>=20 >> $ ./t >> Starting throw-test >> Fatal error during phase 1 unwinding >> Abort (core dumped) >>=20 >> Which indeed is not what I expected. >>=20 >> I=B4ve tried debugging this for a couple of days and have concluded = that my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The = associated code in unwind-arm.c is; >>=20 >> static _Unwind_Reason_Code >> get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) >> { >> const __EIT_entry * eitp; >> int nrec; >>=20 >> /* The return address is the address of the instruction following = the >> call instruction (plus one in thumb mode). If this was the last >> instruction in the function the address will lie in the following >> function. Subtract 2 from the address so that it points within = the call >> instruction itself. */ >> return_address -=3D 2; >>=20 >> if (__gnu_Unwind_Find_exidx) >> { >> eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx = (return_address, >> &nrec); >> if (!eitp) >> { >> UCB_PR_ADDR (ucbp) =3D 0; >> return _URC_FAILURE; >> } >> } >> else >> { >> eitp =3D &__exidx_start; >> nrec =3D &__exidx_end - &__exidx_start; >> } >>=20 >>=20 >> Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an = array located between __exidx_start and __exidx_end. >>=20 >> However, __exidx_end =3D=3D __exidx_start! So the EIT has a length of = zero, nrec will be 0. libgcc will fail the lookup and return = _URC_FAILURE to libcxxrt.cc, which in turn will produce the = fprintf(stderr, "Fatal error during phase 1 unwinding\n"); >>=20 >> # readelf -s t | grep exidx >> 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >> 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >> 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >> 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >>=20 >> So exception throwing in clang++ doesn=B4t seem to work. >>=20 >> Can any of you guys shed some light on this? >>=20 >> Cheers, >>=20 >> /Olavi >=20 > Sadly, all I can do is confirm what you say: C++ exceptions don't = work > on ARM EABI, not with clang and not with gcc. The only combo that = works > is gcc and OABI, but with that combo you lose hardware floating point. >=20 > There are rumours that this may be fixed in clang 3.5, but we = apparently > can't import 3.5 because it can't be bootstrapped using gcc 4.2. I > haven't had time yet to learn how to build clang 3.5 out-of-tree to > confirm that exceptions work there. I=92d like to make one thing perfectly clear, as there=92s some = confusion. As long as we can bootstrap from the last version of the system, the fact that it doesn=92t compile with gcc 4.2 is *NOT* a gating factor. = That=92s never been a requirement for a 3.5 import, and gcc 4.2 is being shown the door for 11.x. I=92ve not had time to try it either. And my time for doing build stuff = has been limited the past month or so. I hope to get back to it in the = coming weeks to resolve some lingering issues, as well as fix the external toolchain support to be completely bootstrapping rather than half bootstrapping like we have today. Warner --Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTyws0AAoJEGwc0Sh9sBEAYuIP/ixtLDJ/6N7cXSKeWp9fKgxv teZ3jBOcBiMlos4NJQ9gj3VLtBcz6QkpQ+SgcjXLlBmJPfDn9RRtvhwUY6jD0gXi eaDo+K0QuNLlrYgNORhkQAEgz9ZjAB0bSQBM1lzqZAyLV4T5QAwf9VQIXj+MUu+p 7GZ53QERqG6Da9eFlkBCUgw8drNiIy96FRo1P6XI6SNLPx56x6LTnanaYhP4ZxDw 0PQqLqF356/MwfhPtJXP4vK+DXSYqtmCCm1+11QUpNEo5WWvJktKk1rJ6wc8qB19 DtCgZqUjgroYiUf740Iz1dTvJ0l0YtTp41eusmxyLtJ1gPnSYa5SEUyhU4OlHH0v yV/qvmuQAi5xEQMgB2tP4kdlyO9I7sG9cyZ2QDdsa5lUg5z8XgXlGuTgyr4mddKv lxgf93gjU6RiV0R18VhisY1TgsLjefmwF7J1QBwUAXXH5qbnnJVIATdhYHShWUnA 9RjoBKvJhgOUyk51/XfeeHtuvgnW2+5VP2sUrFEvI+2nqxrEFvqqg2sYHZSL1baK kzTl/lEwouXyFFzBlglsEWEmdrB9LAJ2w0FGxOO7G+TVm+A2eSWr0CJbhtipu/23 CIQlNJKFWGMDWCT11vAvGobtM9nxARdm5bFq8WP/rDfiZ00dbp2x2NyairnV+d41 b4aeAyh98uylS1DoZHqc =K55l -----END PGP SIGNATURE----- --Apple-Mail=_5A457760-F9C8-4CD9-BD6F-C99DEB039BD7-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 00:49:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 146B8C89 for ; Sun, 20 Jul 2014 00:49:12 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8AFE2EBB for ; Sun, 20 Jul 2014 00:49:11 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X8fJO-000GjT-IH; Sun, 20 Jul 2014 00:49:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6K0n9DK028348; Sat, 19 Jul 2014 18:49:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+B3wuwfDQ/lw85GSduNzoD X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Warner Losh In-Reply-To: <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> References: <1402156516.20883.154.camel@revolution.hippie.lan> <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> Content-Type: text/plain; charset="iso-2022-jp" Date: Sat, 19 Jul 2014 18:49:08 -0600 Message-ID: <1405817348.85788.53.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 00:49:12 -0000 On Sat, 2014-07-19 at 18:20 -0600, Warner Losh wrote: > On Jun 7, 2014, at 9:55 AM, Ian Lepore wrote: > > > On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > >> Hi there, > >> > >> If this question has been discussed before, sorry. I couldn$B!-(Bt find anything when scanning through the archives though. > >> > >> So, I$B!-(Bm running FreeBSD-10/stable on a RPI version B as you can see here; > >> > >> > >> Copyright (c) 1992-2014 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >> The Regents of the University of California. All rights reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 > >> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm > >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > >> > >> > >> I have this little program; > >> > >> $ cat t.cc > >> > >> #include > >> #include > >> > >> void func() > >> { > >> throw std::exception(); > >> } > >> > >> > >> int main() > >> { > >> std::cout << "Starting throw-test" << std::endl; > >> > >> try > >> { > >> func(); > >> } > >> catch(std::exception){ > >> std::cout << $B!H(BIn my exception handler" << std::endl; > >> } > >> catch(...) { > >> std::cout << "In catch-all handler" << std::endl; > >> } > >> > >> return 0; > >> } > >> > >> With this Makefile; > >> > >> $ cat Makefile > >> > >> all : t > >> > >> t : t.cc > >> c++ -o t -fexceptions t.cc > >> > >> > >> Running the above produces the following result; > >> > >> $ ./t > >> Starting throw-test > >> Fatal error during phase 1 unwinding > >> Abort (core dumped) > >> > >> Which indeed is not what I expected. > >> > >> I$B!-(Bve tried debugging this for a couple of days and have concluded that my throw clause ends up in contrib/gcc/config/arm/unwind-arm.c. The associated code in unwind-arm.c is; > >> > >> static _Unwind_Reason_Code > >> get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) > >> { > >> const __EIT_entry * eitp; > >> int nrec; > >> > >> /* The return address is the address of the instruction following the > >> call instruction (plus one in thumb mode). If this was the last > >> instruction in the function the address will lie in the following > >> function. Subtract 2 from the address so that it points within the call > >> instruction itself. */ > >> return_address -= 2; > >> > >> if (__gnu_Unwind_Find_exidx) > >> { > >> eitp = (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_address, > >> &nrec); > >> if (!eitp) > >> { > >> UCB_PR_ADDR (ucbp) = 0; > >> return _URC_FAILURE; > >> } > >> } > >> else > >> { > >> eitp = &__exidx_start; > >> nrec = &__exidx_end - &__exidx_start; > >> } > >> > >> > >> Since __gnu_Unwind_Find_exidx == NULL, the EIT is located in an array located between __exidx_start and __exidx_end. > >> > >> However, __exidx_end == __exidx_start! So the EIT has a length of zero, nrec will be 0. libgcc will fail the lookup and return _URC_FAILURE to libcxxrt.cc, which in turn will produce the fprintf(stderr, "Fatal error during phase 1 unwinding\n"); > >> > >> # readelf -s t | grep exidx > >> 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start > >> 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > >> 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end > >> 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start > >> > >> So exception throwing in clang++ doesn$B!-(Bt seem to work. > >> > >> Can any of you guys shed some light on this? > >> > >> Cheers, > >> > >> /Olavi > > > > Sadly, all I can do is confirm what you say: C++ exceptions don't work > > on ARM EABI, not with clang and not with gcc. The only combo that works > > is gcc and OABI, but with that combo you lose hardware floating point. > > > > There are rumours that this may be fixed in clang 3.5, but we apparently > > can't import 3.5 because it can't be bootstrapped using gcc 4.2. I > > haven't had time yet to learn how to build clang 3.5 out-of-tree to > > confirm that exceptions work there. > > I$B!G(Bd like to make one thing perfectly clear, as there$B!G(Bs some confusion. > As long as we can bootstrap from the last version of the system, the > fact that it doesn$B!G(Bt compile with gcc 4.2 is *NOT* a gating factor. That$B!G(Bs > never been a requirement for a 3.5 import, and gcc 4.2 is being shown > the door for 11.x. > > I$B!G(Bve not had time to try it either. And my time for doing build stuff has > been limited the past month or so. I hope to get back to it in the coming > weeks to resolve some lingering issues, as well as fix the external > toolchain support to be completely bootstrapping rather than half > bootstrapping like we have today. > > Warner I was under the mistaken impression that 3.5 had been released but we hadn't adopted it yet. Yesterday I saw something that said 3.5 is scheduled for release in summer 2015, but I think that was a typo on a news site. Looking deeper just now, it appears to be scheduled for August 2014. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 16:46:57 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5D3F1FC for ; Sun, 20 Jul 2014 16:46:57 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A1E42500 for ; Sun, 20 Jul 2014 16:46:57 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so6108038iec.38 for ; Sun, 20 Jul 2014 09:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a7nlK/Rp2FPou1TXmFSxZCk2CNiMWAZLi+ujUtdCUzs=; b=XYyouB5+liUvlf/Q4m+P4icbZ+T/d2Dpv6JcHjMw2gTTC9/m8xSMQnyl38kyZD6CJ+ jBuOMVNigX6/NlPb9HEz9I6JHZlvKLsZ1M1Xwq80nGSLd/rKPmj1cVFGgjXUOqFas2yY c7t3BZ2hvXvPx1e2bf6Qc+9mJSwe3ADLm4f0G2H0VamSHxNMQJnHJAnecrIGannYjfUB oOO2h/7pTAF+c20Xa647xGzMYe16ehQGh6l7T8h2e65QiDFAHT6Uytyh+36+W/ehcsLu BegU6oAE5ZW3YK6zs/K2Ly9zbF7/F1yvK9qrWs+G9chTq7a6aXWQAnEstA8NwKYqtQxF dJCg== X-Gm-Message-State: ALoCoQnpYPlCrNIZWXQ1MBFNe25brDtwYx5x7QKY+To3nGzZX5Il1ztPXTkVe39fI6W1yqad7VpO X-Received: by 10.50.134.106 with SMTP id pj10mr1311537igb.25.1405874815952; Sun, 20 Jul 2014 09:46:55 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id j5sm29743988ige.12.2014.07.20.09.46.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 09:46:55 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Warner Losh In-Reply-To: <1405817348.85788.53.camel@revolution.hippie.lan> Date: Sun, 20 Jul 2014 10:46:59 -0600 Message-Id: References: <1402156516.20883.154.camel@revolution.hippie.lan> <0591C8AC-22F9-45FC-B959-10FACF8C05C1@bsdimp.com> <1405817348.85788.53.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:46:57 -0000 --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp On Jul 19, 2014, at 6:49 PM, Ian Lepore wrote: > On Sat, 2014-07-19 at 18:20 -0600, Warner Losh wrote: >> On Jun 7, 2014, at 9:55 AM, Ian Lepore wrote: >>=20 >>> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>>> Hi there, >>>>=20 >>>> If this question has been discussed before, sorry. I = couldn=1B$B!-=1B(Bt find anything when scanning through the archives = though. >>>>=20 >>>> So, I=1B$B!-=1B(Bm running FreeBSD-10/stable on a RPI version B as = you can see here; >>>>=20 >>>>=20 >>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >>>> The Regents of the University of California. All rights = reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 10.0-STABLE #0 r266807: Thu May 29 07:07:08 UTC 2014 >>>> root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm >>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 >>>>=20 >>>>=20 >>>> I have this little program; >>>>=20 >>>> $ cat t.cc >>>>=20 >>>> #include >>>> #include >>>>=20 >>>> void func()=20 >>>> { >>>> throw std::exception(); >>>> } >>>>=20 >>>>=20 >>>> int main() >>>> { >>>> std::cout << "Starting throw-test" << std::endl; >>>>=20 >>>> try >>>> { >>>> func(); >>>> } >>>> catch(std::exception){ >>>> std::cout << =1B$B!H=1B(BIn my exception handler" << = std::endl; >>>> } >>>> catch(...) { >>>> std::cout << "In catch-all handler" << std::endl; >>>> } >>>>=20 >>>> return 0; >>>> } >>>>=20 >>>> With this Makefile; >>>>=20 >>>> $ cat Makefile >>>>=20 >>>> all : t >>>>=20 >>>> t : t.cc >>>> c++ -o t -fexceptions t.cc >>>>=20 >>>>=20 >>>> Running the above produces the following result; >>>>=20 >>>> $ ./t >>>> Starting throw-test >>>> Fatal error during phase 1 unwinding >>>> Abort (core dumped) >>>>=20 >>>> Which indeed is not what I expected. >>>>=20 >>>> I=1B$B!-=1B(Bve tried debugging this for a couple of days and have = concluded that my throw clause ends up in = contrib/gcc/config/arm/unwind-arm.c. The associated code in unwind-arm.c = is; >>>>=20 >>>> static _Unwind_Reason_Code >>>> get_eit_entry (_Unwind_Control_Block *ucbp, _uw return_address) >>>> { >>>> const __EIT_entry * eitp; >>>> int nrec; >>>>=20 >>>> /* The return address is the address of the instruction following = the >>>> call instruction (plus one in thumb mode). If this was the last >>>> instruction in the function the address will lie in the = following >>>> function. Subtract 2 from the address so that it points within = the call >>>> instruction itself. */ >>>> return_address -=3D 2; >>>>=20 >>>> if (__gnu_Unwind_Find_exidx) >>>> { >>>> eitp =3D (const __EIT_entry *) __gnu_Unwind_Find_exidx = (return_address, >>>> &nrec); >>>> if (!eitp) >>>> { >>>> UCB_PR_ADDR (ucbp) =3D 0; >>>> return _URC_FAILURE; >>>> } >>>> } >>>> else >>>> { >>>> eitp =3D &__exidx_start; >>>> nrec =3D &__exidx_end - &__exidx_start; >>>> } >>>>=20 >>>>=20 >>>> Since __gnu_Unwind_Find_exidx =3D=3D NULL, the EIT is located in an = array located between __exidx_start and __exidx_end. >>>>=20 >>>> However, __exidx_end =3D=3D __exidx_start! So the EIT has a length = of zero, nrec will be 0. libgcc will fail the lookup and return = _URC_FAILURE to libcxxrt.cc, which in turn will produce the = fprintf(stderr, "Fatal error during phase 1 unwinding\n"); >>>>=20 >>>> # readelf -s t | grep exidx >>>> 36: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >>>> 47: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >>>> 115: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end >>>> 150: 0000a267 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start >>>>=20 >>>> So exception throwing in clang++ doesn=1B$B!-=1B(Bt seem to work. >>>>=20 >>>> Can any of you guys shed some light on this? >>>>=20 >>>> Cheers, >>>>=20 >>>> /Olavi >>>=20 >>> Sadly, all I can do is confirm what you say: C++ exceptions don't = work >>> on ARM EABI, not with clang and not with gcc. The only combo that = works >>> is gcc and OABI, but with that combo you lose hardware floating = point. >>>=20 >>> There are rumours that this may be fixed in clang 3.5, but we = apparently >>> can't import 3.5 because it can't be bootstrapped using gcc 4.2. I >>> haven't had time yet to learn how to build clang 3.5 out-of-tree to >>> confirm that exceptions work there. >>=20 >> I=1B$B!G=1B(Bd like to make one thing perfectly clear, as = there=1B$B!G=1B(Bs some confusion. >> As long as we can bootstrap from the last version of the system, the >> fact that it doesn=1B$B!G=1B(Bt compile with gcc 4.2 is *NOT* a = gating factor. That=1B$B!G=1B(Bs >> never been a requirement for a 3.5 import, and gcc 4.2 is being shown >> the door for 11.x. >>=20 >> I=1B$B!G=1B(Bve not had time to try it either. And my time for doing = build stuff has >> been limited the past month or so. I hope to get back to it in the = coming >> weeks to resolve some lingering issues, as well as fix the external >> toolchain support to be completely bootstrapping rather than half >> bootstrapping like we have today. >>=20 >> Warner >=20 > I was under the mistaken impression that 3.5 had been released but we > hadn't adopted it yet. Yesterday I saw something that said 3.5 is > scheduled for release in summer 2015, but I think that was a typo on a > news site. Looking deeper just now, it appears to be scheduled for > August 2014. Hopefully when released, it will be mature enough for us to include in = 11. Warner --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTy/KDAAoJEGwc0Sh9sBEAYKwP/Apqo3gtg0pPFQmuOkyQKwOq +4eFpw8snENE3Hk3rQST8cW6FdaaAUyR2u6RJkl/2n9gv0ak5qFlkEErG/X1HNYB dS7ANANwGom1Gq3BxnDHtYT1bftH2W754qRhNTrglJpzg1zEt0Pb3hSHRQqTSoJt gywoFNiSY2uG9COEUL+VZru9IAIv7gYJlYh4OvNGUYj51OcshWiek0635jSowyME 3jt2otRvaJdheb880pglPmIb7phFO8CjpBBw/pADRUF2YHgeqGv98dHrM6BpdP0X eQZ3JDJGVLMySgGMn1/Xw8Fj9x3SwySRLddzx5wXKaGhPar8IO2bxcwlPrnTePyJ 4GouVPvn6f4hljvXsimVWfE7daNxAxgmJ4WDNfXwxe7r22BCrasWaY9tLymX9Kur 7g94tOJSJLrRM1yzk8HDF8ZiMtyVYblQ4Ceh7CMDmNc4to4Ar/yJan/hm5N8zqS5 HqUiQeFxH/XnlnCku2c1Q/wPdi8rs9TDnse8rp2+mxwsUw+qIjbk5DPscaCudeAq BK3r2RU1jFAl2g9yTAQAIgvakdmtMB/yls9vrSPvDgzGKEIEFYtmDTEP2BeZElZ9 V7oBeTl1WOQKk7A91mVK+huD/gbiWSOlrYbz2J0aq1Kr43fP3oVZDROXz6gi/FBW 85yLWrIgu1VcDuVo9SGb =9+Q9 -----END PGP SIGNATURE----- --Apple-Mail=_7A32CB17-D7A7-4BB1-97BF-56F1D97E1B29-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 20:00:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A22B66D; Sun, 20 Jul 2014 20:00:12 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B18EE2603; Sun, 20 Jul 2014 20:00:10 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6KJxxIK071916; Sun, 20 Jul 2014 22:00:01 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53CC1FBF.5010401@fgznet.ch> Date: Sun, 20 Jul 2014 21:59:59 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: [Bug 175605] devel/binutils: please fix build binutils-2.23.1 in raspberry pi References: <201407121943.s6CJhT2p097909@mech-cluster241.men.bris.ac.uk> <53C19400.6050404@fgznet.ch> <1405370509.1312.11.camel@revolution.hippie.lan> <9C3614F7-C311-453F-B0E7-BE0312766640@bsdimp.com> <53C58BAA.5040701@fgznet.ch> <1405814269.85788.48.camel@revolution.hippie.lan> In-Reply-To: <1405814269.85788.48.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-13; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:00:12 -0000 On 20.07.14 01:57, Ian Lepore wrote: > On Tue, 2014-07-15 at 22:14 +0200, Andreas Tobler wrote: >> Hi all, >> >> thanks for the feedback! >> >> On 14.07.14 22:45, Warner Losh wrote: >>> >>> On Jul 14, 2014, at 2:41 PM, Ian Lepore wrote: >>> >>>> On Sat, 2014-07-12 at 22:01 +0200, Andreas Tobler wrote: >>>>> On 12.07.14 21:43, Anton Shterenlikht wrote: >>>>>>>> --- Comment #6 from mexas@bris.ac.uk --- >>>>>>>> Forgot to say that this was with Andreas Tobler's patchset. >>>>>>>> Also, it segfaults with the OS default ld too: >>>>>>>> >>>>>>>> $ cat z.c >>>>>>>> #include >>>>>>>> int main(int argc, char **argv) >>>>>>>> { >>>>>>>> printf("mumu\n"); >>>>>>>> return 0; >>>>>>>> } >>>>>>>> $ cc -c z.c -Wall >>>>>>>> $ /usr/local/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>>>> $ ldd z >>>>>>>> z: >>>>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>>>> $ file z >>>>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>>>> $ ./z >>>>>>>> Segmentation fault (core dumped) >>>>>>>> $ /usr/bin/ld -o z /usr/lib/crt1.o /usr/lib/crti.o z.o -lc >>>>>>>> $ ldd z >>>>>>>> z: >>>>>>>> libc.so.7 => /lib/libc.so.7 (0x2003c000) >>>>>>>> $ file z >>>>>>>> z: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses >>>>>>>> shared libs), for FreBSD 10.0 (1000710), not stripped >>>>>>>> $ ./z >>>>>>>> Segmentation fault (core dumped) >>>>>>>> $ >>>>>>>> >>>>>>> Why are you using this strange invocation of the linker? If I run >>>>>>> "cc -v -o z z.c", here is how it invokes ld: >>>>>>> >>>>>>> "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 >>>>>>> --hash-style=both --enable-new-dtags -o z /usr/lib/crt1.o >>>>>>> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/z-9530c3.o -lgcc >>>>>>> --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s >>>>>>> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >>>>>>> >>>>>>> The resulting program runs without difficulty. -- George >>>>>> >>>>>> well, I copied my invocation from: >>>>>> http://people.freebsd.org/~rene/patches/binutils-rpi-bug.txt >>>>>> >>>>>> but you are right. I have now did just the same >>>>>> using /usr/local/bin/ld, and the executable worked. >>>>>> >>>>>> So probably Andreas Tobler's patchset should >>>>>> be committed? >>>>>> >>>>>> I'm building lang/gcc right now, will see how it goes. >>>>> >>>>> You can save the time for gcc. Nothing else than the system gcc works. >>>>> I do some work on gcc-4.10 and it is hairy. >>>>> I can bootstrap gcc-4.10 but I have some issues with tls which blocks me >>>>> to come out with my patch set. The overall view is good. >>>> >>>> >>>>> I even have C++ exceptions working with EABI. >>>> >>>> We are actively working on this at $work (using clang, not gcc) and I'd >>>> love to see whatever patches you've got. I was about to import netbsd's >>>> find_exidx.c for ld-elf.so, but if you've already done it I won't >>>> bother. There are other aspects of it still not working for us, so >>>> maybe you've solved things we're still working on. >>>> >>>>> >>>>> Also, the binutils patch set is not satisfying for me. I do not have >>>>> feedback for arm*b nor for arm* < FreeBSD 10.0. >>>>> >>>> >>>> I doubt you'll ever get feedback for either of these. We only have 2 or >>>> 3 users who have hardware and are even trying to use armeb these days. >>>> The hardware is old and rare. -current only became usable again on >>>> armeb in the past week or two. >>>> >>>> As for arm on < 10, there's not much support. and not many active users. >>>> It's not an official project policy or anything, but in effect we've >>>> abandoned active support on anything older than 10 due to lack of >>>> resources. We use 8.2 with arm at work, and all the patches we've >>>> generated there over the years have been merged to 8, 10, and 11. >>>> >>>> 9.x on arm has always been a nonexistant thing for me. I don't know of >>>> anybody even trying to use it, based on the traffic on irc and mailing >>>> lists. >>> >>> I have a 9.x arm-based (atmel) dhcpd and other network services server that >>> I run since I couldnÿt get the 10.x MCI driver on atmel to work on the newer SAM9 >>> SoCs. All the optimizations for it work great on the AT91RM9200, but break newer >>> ones. >>> >>> That said, there are a number of bumps in the 9.x support in arm. :( Iÿve worked >>> around them, but most of the issues have since been fixed in -current and 10. >> >> My issue is here: >> >> +++ gas/configure.tgt 1970-01-01 00:16:31.000000000 +0000 >> @@ -136,6 +136,9 @@ >> arm-*-symbianelf*) fmt=elf em=symbian ;; >> arm-*-kaos*) fmt=elf ;; >> arm-*-conix*) fmt=elf ;; >> + arm-*-freebsd9* | armeb-*-freebsd9*) fmt=elf em=freebsd ;; >> + arm-*-freebsd* | armeb-*-freebsd*) fmt=elf em=armfbsdeabi ;; >> + arm*-*-freebsd*) fmt=elf em=armfbsdvfp ;; >> >> fyi: >> -> armfbsdeabi sets EABI_DEFAULT EF_ARM_EABI_VER5 >> and >> -> armfbsdvfp sets the same as armfbsdeabi plus FPU_DEFAULT FPU_ARCH_VFP >> >> On freebsd9 I leave the 'old' abi and I'm not sure if I should do so. As >> I understand you both, 9.x is not something official working. It works >> if one puts his hands on it and does the mods needed. >> > > Using OABI on 9 is correct, I don't think the EABI support will ever be > MFC'd to 9. ok. >> On 10.x and up we have the eabi and everthing is nearly fine. Except the >> vfp support which is only for armv6* and up. Here I'm not so sure if I >> do the right thing. >> The test cases look right, around 4 fails of 500 tests on my arm- and my >> armv6 board. >> > > I think you've got it right... arm and armeb use EABI without VFP, and > armv6 and armv6hf are EABI with VFP. ok. > In theory we can do OABI without VFP on armv6, but I haven't tested that > for more than a year. OABI with VFP isn't an option. I'll go ahead by the end of the coming week, after my vacation. Thanks again and also thanks for the exidx stuff. Works fine here. Andreas From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 22:05:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50F959E3; Sun, 20 Jul 2014 22:05:16 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C42B2152; Sun, 20 Jul 2014 22:05:15 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6KM5Eui025717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 15:05:15 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6KM5ETE025716; Sun, 20 Jul 2014 15:05:14 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Jul 2014 15:05:14 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140720220514.GP45513@funkthat.com> Mail-Followup-To: Ian Lepore , Fabien Thomas , freebsd-arm@freebsd.org, arch@FreeBSD.org References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1405810447.85788.41.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Jul 2014 15:05:15 -0700 (PDT) Cc: arch@freebsd.org, freebsd-arm@freebsd.org, Fabien Thomas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:05:16 -0000 Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > Sorry to take so long to reply to this, I'm trying to get caught up. I > see you've already committed the mge fixes. I think the ELF alignment > fix looks good and should also be committed. So, re the elf alignment... I think we should get a set of macros that handle load/stores to/from unaligned addresses that are transparent to the caller.... I need these for some other code I'm writing... I thought Open/Net had these available, but I can't seem to find them right now... Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 22:25:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8C253E2 for ; Sun, 20 Jul 2014 22:25:19 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 919BC2306 for ; Sun, 20 Jul 2014 22:25:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6KLw1sX025596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 14:58:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6KLw1D3025595; Sun, 20 Jul 2014 14:58:01 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Jul 2014 14:58:00 -0700 From: John-Mark Gurney To: Anton Shterenlikht Subject: Re: sound on RPi-B? Message-ID: <20140720215800.GO45513@funkthat.com> Mail-Followup-To: Anton Shterenlikht , freebsd-arm@freebsd.org References: <201407081954.s68Jsk7q066069@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407081954.s68Jsk7q066069@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Jul 2014 14:58:02 -0700 (PDT) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:25:19 -0000 Anton Shterenlikht wrote this message on Tue, Jul 08, 2014 at 20:54 +0100: > If I want sound from an RPi-B, do I just > follow the handbook, or are there any > special considerations? > In particular, it seems I can draw sound > in 2 ways, via a dedicated sound port, > or via HDMI. I'm using an HDMI to VGA > adapter that provides a separate sound > output. I see there is no sound driver > in the default kernel, but since HDMI > is supported, I wonder if I have sound > support already? It looks like we just use the VideoCore services, and there isn't a sound driver yet... I'm not familar w/ the RPI, but it looks like for now, you'll need to use a USB sound adapter... This should work as I've recently gotten USB sound working on my BBB... Good luck... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 22:44:13 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33469C71; Sun, 20 Jul 2014 22:44:13 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E44124A8; Sun, 20 Jul 2014 22:44:12 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s6KMPYm2034654; Sun, 20 Jul 2014 22:25:35 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id vdaw6hpf82wki98ffnynjfr39i; Sun, 20 Jul 2014 22:25:34 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Tim Kientzle In-Reply-To: <20140720220514.GP45513@funkthat.com> Date: Sun, 20 Jul 2014 15:25:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org, freebsd-arm@freebsd.org, Fabien Thomas , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:44:13 -0000 On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: >> Sorry to take so long to reply to this, I'm trying to get caught up. I >> see you've already committed the mge fixes. I think the ELF alignment >> fix looks good and should also be committed. > > So, re the elf alignment... > > I think we should get a set of macros that handle load/stores to/from > unaligned addresses that are transparent to the caller.... I need > these for some other code I'm writing... > > I thought Open/Net had these available, but I can't seem to find them > right now... $ man 9 byteorder is most of what you want, lacking only some aliases to pick the correct macro for native byte order. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Jul 20 23:10:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36AA3CC2; Sun, 20 Jul 2014 23:10:59 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E6AFB2766; Sun, 20 Jul 2014 23:10:58 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6KNAubX026526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2014 16:10:57 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6KNAu2a026525; Sun, 20 Jul 2014 16:10:56 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Jul 2014 16:10:56 -0700 From: John-Mark Gurney To: Tim Kientzle Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140720231056.GQ45513@funkthat.com> Mail-Followup-To: Tim Kientzle , Ian Lepore , arch@freebsd.org, freebsd-arm@freebsd.org, Fabien Thomas References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Jul 2014 16:10:57 -0700 (PDT) Cc: arch@freebsd.org, freebsd-arm@freebsd.org, Fabien Thomas , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:10:59 -0000 Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > > On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > > > Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >> Sorry to take so long to reply to this, I'm trying to get caught up. I > >> see you've already committed the mge fixes. I think the ELF alignment > >> fix looks good and should also be committed. > > > > So, re the elf alignment... > > > > I think we should get a set of macros that handle load/stores to/from > > unaligned addresses that are transparent to the caller.... I need > > these for some other code I'm writing... > > > > I thought Open/Net had these available, but I can't seem to find them > > right now... > > $ man 9 byteorder > > is most of what you want, lacking only some aliases to pick > the correct macro for native byte order. Um, those doesn't help if you want native endian order... Also, only the enc/dec functions are documented to work on non-aligned address, so that doesn't help in most cases... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 00:56:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DA17D7C for ; Mon, 21 Jul 2014 00:56:43 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42DAE2F88 for ; Mon, 21 Jul 2014 00:56:43 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id g10so8251232pdj.29 for ; Sun, 20 Jul 2014 17:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=tkmVc9RMamXGwam8kjkGVReUc3n4x9VppXRIUTopVo4=; b=DmIH+lWrHxCOhW30ezdyCA329SLadlcmrBd+KnDk85+6mdilsuZ70Dq35ocMaMp9sW Tu2WEtcZOcHbWNhlLY1fIV18U2EzEOPPBVf9P7wHj0fwtjBnNbOX9NWdnMnkhr8vA0hy KrfzTB4RNBA29El8DBYpG95dSvprwkhob3DJ1LpOhyP8uCo+FlO0NJJHdVm8mv1lZvaN spk8rCcZgLIyydBo3vpPb0lD4O+QVnuorZnhK9aFwe8oe+7gzIIiLYVm9Gi9/N9J6dKm 8vT/23ChUA+8jpcLi0QL7qFlRAtL4jsiFinnnd+oVAarPlMYdIKl0saJSOHEiNkCjtDt zmYQ== X-Received: by 10.70.131.134 with SMTP id om6mr21654086pdb.95.1405904202339; Sun, 20 Jul 2014 17:56:42 -0700 (PDT) Received: from [172.16.1.21] (123-100-93-24.dynamic.dsl.netguardian.co.nz. [123.100.93.24]) by mx.google.com with ESMTPSA id ek2sm12347192pbd.30.2014.07.20.17.56.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 17:56:41 -0700 (PDT) From: Stephen Woolerton Subject: Compiling clang33 port on Raspberry Pi Message-Id: Date: Mon, 21 Jul 2014 12:56:35 +1200 To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:56:43 -0000 Hi everyone, I'm would like to install the clang33 package on a Raspberry Pi running = 10.0-STABLE (r268038). I compiled the clang33 port on the Pi and it = crashed as outlined below.=20 I'm hoping someone can give me a hand to get the crash resolved, or = maybe there is another way of getting clang33 installed. Note: Regarding LibraryDependencies.inc, I googled and found that this = issue can occur if python v2 is not available. Python27 is installed on = this system but no "python" binary, and so I symlinked python27 to = python in /usr/local/bin, but still the same fault.=20 Thank you Stephen -------------------- ... llvm-build: error: invalid native target: 'armv6' (not in project) llvm[3]: Linking Release Shared Library libLLVM-3.3.so gmake[3]: Leaving directory = `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-shlib' gmake[3]: Entering directory = `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' llvm[3]: Constructing LLVMBuild project information. Usage: llvm-build [options] llvm-build: error: invalid native target: 'armv6' (not in project) llvm[3]: Building llvm-config BuildVariables.inc file. llvm[3]: Compiling llvm-config.cpp for Release build llvm-config.cpp:45:10: fatal error: 'LibraryDependencies.inc' file not = found #include "LibraryDependencies.inc" ^ 1 error generated. rm: = /usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-c= onfig.d.tmp: No such file or directory gmake[3]: *** = [/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-= config.o] Error 1 gmake[3]: Leaving directory = `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/llvm33 *** Error code 1 Stop. make: stopped in /usr/ports/devel/llvm33 =3D=3D=3D>>> make build failed for devel/llvm33 =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for devel/llvm33 failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for lang/clang33 failed =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster lang/clang33 devel/llvm33=20 From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 01:48:10 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6608588 for ; Mon, 21 Jul 2014 01:48:10 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 749612345 for ; Mon, 21 Jul 2014 01:48:10 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X92hv-0003SG-DX; Mon, 21 Jul 2014 01:48:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6L1m2vc030517; Sun, 20 Jul 2014 19:48:02 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+LbUrl+tmWrAJGHXUBcgl1 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compiling clang33 port on Raspberry Pi From: Ian Lepore To: Stephen Woolerton In-Reply-To: References: Date: Sun, 20 Jul 2014 19:48:02 -0600 Message-ID: <1405907282.85788.64.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:48:10 -0000 On Mon, 2014-07-21 at 12:56 +1200, Stephen Woolerton wrote: > Hi everyone, > > I'm would like to install the clang33 package on a Raspberry Pi running 10.0-STABLE (r268038). I compiled the clang33 port on the Pi and it crashed as outlined below. > > I'm hoping someone can give me a hand to get the crash resolved, or maybe there is another way of getting clang33 installed. > Note: Regarding LibraryDependencies.inc, I googled and found that this issue can occur if python v2 is not available. Python27 is installed on this system but no "python" binary, and so I symlinked python27 to python in /usr/local/bin, but still the same fault. > > Thank you > Stephen > -------------------- > ... > > llvm-build: error: invalid native target: 'armv6' (not in project) > llvm[3]: Linking Release Shared Library libLLVM-3.3.so > gmake[3]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-shlib' > gmake[3]: Entering directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' > llvm[3]: Constructing LLVMBuild project information. > Usage: llvm-build [options] > > llvm-build: error: invalid native target: 'armv6' (not in project) > llvm[3]: Building llvm-config BuildVariables.inc file. > llvm[3]: Compiling llvm-config.cpp for Release build > llvm-config.cpp:45:10: fatal error: 'LibraryDependencies.inc' file not found > #include "LibraryDependencies.inc" > ^ > 1 error generated. > rm: /usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-config.d.tmp: No such file or directory > gmake[3]: *** [/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-config.o] Error 1 > gmake[3]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' > gmake[2]: *** [all] Error 1 > gmake[2]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/devel/llvm33 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/devel/llvm33 > > ===>>> make build failed for devel/llvm33 > ===>>> Aborting update > > ===>>> Update for devel/llvm33 failed > ===>>> Aborting update > > ===>>> Update for lang/clang33 failed > ===>>> Aborting update > > > ===>>> You can restart from the point of failure with this command line: > portmaster lang/clang33 devel/llvm33 I had the same problem today trying to build llvm-devel and clang-devel (clang 3.5) on a wandboard. The actual problem is "llvm-build: error: invalid native target: 'armv6' (not in project)"; it leads to the dependencies not being built. Try copying the attached file into the files directory of *both* the llvm and clang ports, replacing the same-named file already there, then do a make clean and start the build over. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 03:39:30 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59A9C91 for ; Mon, 21 Jul 2014 03:39:30 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA692D7B for ; Mon, 21 Jul 2014 03:39:29 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X94Rk-0002eK-4G for freebsd-arm@FreeBSD.org; Mon, 21 Jul 2014 03:39:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6L3dRXb031604 for ; Sun, 20 Jul 2014 21:39:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18Y1CLV17onWIjOR+DrcWix X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compiling clang33 port on Raspberry Pi From: Ian Lepore To: FreeBSD ARM In-Reply-To: <1405907282.85788.64.camel@revolution.hippie.lan> References: <1405907282.85788.64.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Jul 2014 21:39:26 -0600 Message-ID: <1405913966.85788.66.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:39:30 -0000 On Sun, 2014-07-20 at 19:48 -0600, Ian Lepore wrote: > On Mon, 2014-07-21 at 12:56 +1200, Stephen Woolerton wrote: > > Hi everyone, > > > > I'm would like to install the clang33 package on a Raspberry Pi running 10.0-STABLE (r268038). I compiled the clang33 port on the Pi and it crashed as outlined below. > > > > I'm hoping someone can give me a hand to get the crash resolved, or maybe there is another way of getting clang33 installed. > > Note: Regarding LibraryDependencies.inc, I googled and found that this issue can occur if python v2 is not available. Python27 is installed on this system but no "python" binary, and so I symlinked python27 to python in /usr/local/bin, but still the same fault. > > > > Thank you > > Stephen > > -------------------- > > ... > > > > llvm-build: error: invalid native target: 'armv6' (not in project) > > llvm[3]: Linking Release Shared Library libLLVM-3.3.so > > gmake[3]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-shlib' > > gmake[3]: Entering directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' > > llvm[3]: Constructing LLVMBuild project information. > > Usage: llvm-build [options] > > > > llvm-build: error: invalid native target: 'armv6' (not in project) > > llvm[3]: Building llvm-config BuildVariables.inc file. > > llvm[3]: Compiling llvm-config.cpp for Release build > > llvm-config.cpp:45:10: fatal error: 'LibraryDependencies.inc' file not found > > #include "LibraryDependencies.inc" > > ^ > > 1 error generated. > > rm: /usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-config.d.tmp: No such file or directory > > gmake[3]: *** [/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config/Release/llvm-config.o] Error 1 > > gmake[3]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src/tools/llvm-config' > > gmake[2]: *** [all] Error 1 > > gmake[2]: Leaving directory `/usr/ports/devel/llvm33/work/llvm-3.3.src' > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > the maintainer. > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/devel/llvm33 > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/devel/llvm33 > > > > ===>>> make build failed for devel/llvm33 > > ===>>> Aborting update > > > > ===>>> Update for devel/llvm33 failed > > ===>>> Aborting update > > > > ===>>> Update for lang/clang33 failed > > ===>>> Aborting update > > > > > > ===>>> You can restart from the point of failure with this command line: > > portmaster lang/clang33 devel/llvm33 > > I had the same problem today trying to build llvm-devel and clang-devel > (clang 3.5) on a wandboard. The actual problem is "llvm-build: error: > invalid native target: 'armv6' (not in project)"; it leads to the > dependencies not being built. > > Try copying the attached file into the files directory of *both* the > llvm and clang ports, replacing the same-named file already there, then > do a make clean and start the build over. > > -- Ian > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hrm, apparently the attachment got scrubbed from the list, presumably because the filename ended in .py. There are no tabs or anything in it, so I'll just paste it here... --- utils/llvm-build/llvmbuild/main.py.orig 2014-04-23 19:17:42 +0000 +++ utils/llvm-build/llvmbuild/main.py 2014-07-20 14:45:44 +0000 @@ -699,7 +699,16 @@ # We handle a few special cases of target names here for historical # reasons, as these are the names configure currently comes up with. - native_target_name = { 'x86' : 'X86', + native_target_name = { 'amd64' : 'X86', + 'arm' : 'ARM', + 'armeb' : 'ARM', + 'armv6' : 'ARM', + 'armv6hf' : 'ARM', + 'i386' : 'X86', + 'mips' : 'Mips', + 'powerpc' : 'PowerPC', + 'sparc64' : 'Sparc', + 'x86' : 'X86', 'x86_64' : 'X86', 'Unknown' : None }.get(opts.native_target, opts.native_target) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 08:46:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6ED1D80; Mon, 21 Jul 2014 08:46:31 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3B38228E7; Mon, 21 Jul 2014 08:46:30 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 2FC642700A00; Mon, 21 Jul 2014 10:40:57 +0200 (CEST) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 08F042700AAC; Mon, 21 Jul 2014 10:40:57 +0200 (CEST) Received: from [10.2.1.1] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id A07022700A00; Mon, 21 Jul 2014 10:40:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Fabien Thomas In-Reply-To: <20140720231056.GQ45513@funkthat.com> Date: Mon, 21 Jul 2014 10:40:55 +0200 Message-Id: References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> To: John-Mark Gurney , Ian Lepore , Tim Kientzle X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 08:46:31 -0000 On 21 Jul 2014, at 01:10, John-Mark Gurney wrote: > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: >>=20 >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: >>=20 >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: >>>> Sorry to take so long to reply to this, I'm trying to get caught = up. I >>>> see you've already committed the mge fixes. I think the ELF = alignment >>>> fix looks good and should also be committed. >>>=20 >>> So, re the elf alignment... >>>=20 >>> I think we should get a set of macros that handle load/stores = to/from >>> unaligned addresses that are transparent to the caller.... I need >>> these for some other code I'm writing...=20 >>>=20 >>> I thought Open/Net had these available, but I can't seem to find = them >>> right now... >>=20 >> $ man 9 byteorder >>=20 >> is most of what you want, lacking only some aliases to pick >> the correct macro for native byte order. >=20 > Um, those doesn't help if you want native endian order... >=20 > Also, only the enc/dec functions are documented to work on non-aligned > address, so that doesn't help in most cases... Yes, having an API to read unaligned pointer is better than than using = local fix like in the patch. Tell me if you add one and I can adapt the patch. Fabien >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 14:46:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C03C81AD for ; Mon, 21 Jul 2014 14:46:45 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 827192DE9 for ; Mon, 21 Jul 2014 14:46:45 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at20so6963483iec.11 for ; Mon, 21 Jul 2014 07:46:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=A5erOhAY4+GeP9su/j+jYVNuXCwQ35/Ztm9Cc2Qi4mk=; b=YO9GF8lwp5rdxZiMwGOJ+dxzmU27AompM4hMGjos5wRllvy7UCUdj+Wbu65ZS8ppi1 xnJRQH/gDH4T3Qstev7ivJ+v8Un2u1kvoHwKhr9moehzVqBkDVnBHfBP5KewBj0rTuP9 kaiHBHF3oVDbXpj0iGglNzvNkAw4RsqXbw7qnOyhhBq3/aaC/8PbsaRqHnakYKvbRKlH f+KV2FkcS6YQI7X7dyzHtx6Mh1zG+pt4Xs3uRhACCixyCMqOXas8kSYwIOXQ5MfIT5Yg x6u01U53I8ThfyCqwwKOoVIzvmX6kFftCA4mXJOBhFTDyNDX8H+lAuygZNkqO1XZIlw1 PVfQ== X-Gm-Message-State: ALoCoQkSUmZH2c7szTunykQPyBZsTYJ5qhejC9apisX7Pm/sDVX7pRB2nPzsPTlMTccS9o2bBPxj X-Received: by 10.50.43.202 with SMTP id y10mr5984003igl.10.1405953999771; Mon, 21 Jul 2014 07:46:39 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id hu5sm18932790igb.16.2014.07.21.07.46.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 07:46:39 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_034E84E0-2852-49EA-AC44-CF120A14ECC5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Warner Losh In-Reply-To: <20140720231056.GQ45513@funkthat.com> Date: Mon, 21 Jul 2014 08:46:49 -0600 Message-Id: <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:46:45 -0000 --Apple-Mail=_034E84E0-2852-49EA-AC44-CF120A14ECC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: >>=20 >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: >>=20 >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: >>>> Sorry to take so long to reply to this, I'm trying to get caught = up. I >>>> see you've already committed the mge fixes. I think the ELF = alignment >>>> fix looks good and should also be committed. >>>=20 >>> So, re the elf alignment... >>>=20 >>> I think we should get a set of macros that handle load/stores = to/from >>> unaligned addresses that are transparent to the caller.... I need >>> these for some other code I'm writing...=20 >>>=20 >>> I thought Open/Net had these available, but I can't seem to find = them >>> right now... >>=20 >> $ man 9 byteorder >>=20 >> is most of what you want, lacking only some aliases to pick >> the correct macro for native byte order. >=20 > Um, those doesn't help if you want native endian order=85 Ummm, yes they do. enc converts from native order. dec decodes to native = byte order. They are more general cases than the ntoh* functions that are = more traditional since they also work on byte streams that may not be completely aligned = when sitting in memory. Which is what you are asking for. > Also, only the enc/dec functions are documented to work on non-aligned > address, so that doesn't help in most cases=85 They work on all addresses. They are even documented to work on any = address: The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), = be64dec(), le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and = le64dec() functions encode and decode integers to/from byte strings on any = align- ment in big/little endian format. So they are quite useful in general. Peeking under the covers at the = implementation also shows they will work for any alignment, so I=92m having trouble = understanding where this objection is really coming from. Warner --Apple-Mail=_034E84E0-2852-49EA-AC44-CF120A14ECC5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzSfZAAoJEGwc0Sh9sBEAtwQQANWF//KOUKKWQ4IVrQUwsOVf BAGJz6ulwAR/lAt22Wx8jXyxGcl/uKql6nxmsakPSgOB/9Pb+iqkkYUmsAjlrK9J iXYQ/QtkJmdht8VZUkabIovz/KRpP2r1qLwszVoo/lSUb5OBM9bI8zVmNaFCsvIS SvUPzrz1VLjYlGSTVXvSXN+Qd46J750cs9Hb19CnbRZ5pZ0pRzUIufY/G+XdzJqX TLAxasKDdYtXIUbOydNpucD9wA5tiiMajQRJyFaZuBv5SkfPH6BTac/XYrJz8uc7 bW1rkANW0THGVPQFjETh5VvkK/TlDDUIgJ/lFhwf/ZvtsAgT0mKTUK6twHc0N4Sn EuJer92IuDfqCIdmlQ0eyzvgLCsGRM3Pr6OCZwYUmwQ4k8JQEF9hmM4o/RzUocue HiG1NPwLZNVx84xr0+5wr9TC71hHBcG7goIAdoxY0cinJFiwK3E1zg4Dr8pRicf0 HJpsTq9lGHy7x6fEN25akJM0I3I3Eph8DgazazaSi0vMDSRqMOPsvjUgQ3e9Bzo2 /QGjI8miyXR8US341cS2VxugI0y2PSmwUYrFymbMKgSlTvJYXV2yKhPPoT7nVcpO NDpnfDf5EHT2q9eYr1iKs5y09Ed1QyBnOA/6VLKDPVIjptYpcxZk/xGd7Vm61cOX Ula38Jy3qNhbDLxuHzSQ =IL3U -----END PGP SIGNATURE----- --Apple-Mail=_034E84E0-2852-49EA-AC44-CF120A14ECC5-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 15:04:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AACAA840; Mon, 21 Jul 2014 15:04:18 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A1822FCD; Mon, 21 Jul 2014 15:04:18 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X9F8M-000NPd-MH; Mon, 21 Jul 2014 15:04:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6LF49ek032726; Mon, 21 Jul 2014 09:04:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19AoiW6fTllgrCw/54MlGPe X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] mge driver / elf reloc From: Ian Lepore To: Warner Losh In-Reply-To: <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Mon, 21 Jul 2014 09:04:08 -0600 Message-ID: <1405955048.85788.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s6LF49ek032726 Cc: arch@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:04:18 -0000 On Mon, 2014-07-21 at 08:46 -0600, Warner Losh wrote: > On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: >=20 > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >>=20 > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wro= te: > >>=20 > >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >>>> Sorry to take so long to reply to this, I'm trying to get caught u= p. I > >>>> see you've already committed the mge fixes. I think the ELF align= ment > >>>> fix looks good and should also be committed. > >>>=20 > >>> So, re the elf alignment... > >>>=20 > >>> I think we should get a set of macros that handle load/stores to/fr= om > >>> unaligned addresses that are transparent to the caller.... I need > >>> these for some other code I'm writing...=20 > >>>=20 > >>> I thought Open/Net had these available, but I can't seem to find th= em > >>> right now... > >>=20 > >> $ man 9 byteorder > >>=20 > >> is most of what you want, lacking only some aliases to pick > >> the correct macro for native byte order. > >=20 > > Um, those doesn't help if you want native endian order=85 >=20 > Ummm, yes they do. enc converts from native order. dec decodes to nativ= e byte > order. They are more general cases than the ntoh* functions that are mo= re traditional > since they also work on byte streams that may not be completely aligned= when > sitting in memory. Which is what you are asking for. >=20 > > Also, only the enc/dec functions are documented to work on non-aligne= d > > address, so that doesn't help in most cases=85 >=20 > They work on all addresses. They are even documented to work on any add= ress: >=20 > The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec= (), > le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec= () > functions encode and decode integers to/from byte strings on any a= lign- > ment in big/little endian format. >=20 > So they are quite useful in general. Peeking under the covers at the im= plementation > also shows they will work for any alignment, so I=92m having trouble un= derstanding > where this objection is really coming from. >=20 > Warner >=20 The functionality requested was alignment-safe copy/assign without any endian change. The code in question was conceptually something like =20 if (pointer & 0x03) do-alignment-safe-thing else directly-deref-the-pointer -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 16:26:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4B966BA; Mon, 21 Jul 2014 16:26:01 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC4E827DC; Mon, 21 Jul 2014 16:26:01 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6LGPxp8041488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 09:26:00 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6LGPxia041487; Mon, 21 Jul 2014 09:25:59 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Jul 2014 09:25:59 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140721162559.GS45513@funkthat.com> Mail-Followup-To: Warner Losh , Tim Kientzle , arch@freebsd.org, freebsd-arm , Fabien Thomas , Ian Lepore References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Jul 2014 09:26:00 -0700 (PDT) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:26:02 -0000 Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: > > On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: > > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >> > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > >> > >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >>>> Sorry to take so long to reply to this, I'm trying to get caught up. I > >>>> see you've already committed the mge fixes. I think the ELF alignment > >>>> fix looks good and should also be committed. > >>> > >>> So, re the elf alignment... > >>> > >>> I think we should get a set of macros that handle load/stores to/from > >>> unaligned addresses that are transparent to the caller.... I need > >>> these for some other code I'm writing... > >>> > >>> I thought Open/Net had these available, but I can't seem to find them > >>> right now... > >> > >> $ man 9 byteorder > >> > >> is most of what you want, lacking only some aliases to pick > >> the correct macro for native byte order. > > > > Um, those doesn't help if you want native endian order? > > Ummm, yes they do. enc converts from native order. dec decodes to native byte No they don't.. If you want to read a value in memory that is native endian order to native endian order (no conversion), they cannot be used w/o using something like below... > order. They are more general cases than the ntoh* functions that are more traditional > since they also work on byte streams that may not be completely aligned when > sitting in memory. Which is what you are asking for. So, you're saying that I now need to write code like: #if LITTLE_ENDIAN /* or how ever this is spelled*/ var = le32enc(foo); #else var = be32enc(foo); #endif If I want to read a arch native endian value? No thank you... > > Also, only the enc/dec functions are documented to work on non-aligned > > address, so that doesn't help in most cases? > > They work on all addresses. They are even documented to work on any address: > > The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec(), > le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec() > functions encode and decode integers to/from byte strings on any align- > ment in big/little endian format. > > So they are quite useful in general. Peeking under the covers at the implementation > also shows they will work for any alignment, so I?m having trouble understanding > where this objection is really coming from. There are places where you write code such as: int i; memcpy(&i, inp, sizeof i); /* use i */ In order to avoid alignment faults... None of the functions in byteorder do NO conversion of endian, or you have to know which endian you are but that doesn't work on MI code... Did you read what the commited code did? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 16:31:50 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4670F824 for ; Mon, 21 Jul 2014 16:31:50 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 026622825 for ; Mon, 21 Jul 2014 16:31:49 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so7109669iec.10 for ; Mon, 21 Jul 2014 09:31:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wDeDoNSXcf7CdkYzdv5YdOLpCzIvdO6tHRVSoCK1RKA=; b=nJ3YmfeBwJZ5e6RktDDb4/AKLcKw67pK/ZLBS6OnmKWiIMZlOkgkvW53DEWR0mI9R6 QpTnoAIcPgdmFlELgMnjIusDqPEeFY52HQUihZP0MrlQALaq+lMdTsg5JVKnnxPIIXih /2f6LGa/OrWrN/lh3KI8qisMcjZdqCfbYzE9IYmoT8OCDxqA3V7WNTxWQOY/EfADUxX9 i47HpxR4ioeyLV1lsrA00pVS4bBTEaNINh8yinvxGoFTndWgFWGV3ZejaeNDYFBZILHu OOduRi4bNwDwaqqzRzN+q9xBfgqP+QnxgmiVaUVs1J6eJTWSpvVpTgjw2bDDQl0Sp5wv MoLA== X-Gm-Message-State: ALoCoQmzvPaaeTNJZ5y4RY/K1LSyAEsZQBQ+3lHtsoDMMet5pnlQYlfByhwErc2XoowX5pCzLB7k X-Received: by 10.50.153.83 with SMTP id ve19mr7156700igb.4.1405960303422; Mon, 21 Jul 2014 09:31:43 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o9sm2673343igv.18.2014.07.21.09.31.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 09:31:42 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Warner Losh In-Reply-To: <20140721162559.GS45513@funkthat.com> Date: Mon, 21 Jul 2014 10:31:40 -0600 Message-Id: <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:31:50 -0000 --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 21, 2014, at 10:25 AM, John-Mark Gurney wrote: > Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: >>=20 >> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney = wrote: >>=20 >>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: >>>>=20 >>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: >>>>=20 >>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: >>>>>> Sorry to take so long to reply to this, I'm trying to get caught = up. I >>>>>> see you've already committed the mge fixes. I think the ELF = alignment >>>>>> fix looks good and should also be committed. >>>>>=20 >>>>> So, re the elf alignment... >>>>>=20 >>>>> I think we should get a set of macros that handle load/stores = to/from >>>>> unaligned addresses that are transparent to the caller.... I need >>>>> these for some other code I'm writing...=20 >>>>>=20 >>>>> I thought Open/Net had these available, but I can't seem to find = them >>>>> right now... >>>>=20 >>>> $ man 9 byteorder >>>>=20 >>>> is most of what you want, lacking only some aliases to pick >>>> the correct macro for native byte order. >>>=20 >>> Um, those doesn't help if you want native endian order? >>=20 >> Ummm, yes they do. enc converts from native order. dec decodes to = native byte >=20 > No they don't.. If you want to read a value in memory that is native > endian order to native endian order (no conversion), they cannot be > used w/o using something like below=85 Missed the native to native. bcopy works, but is ugly, as you note = below. >> order. They are more general cases than the ntoh* functions that are = more traditional >> since they also work on byte streams that may not be completely = aligned when >> sitting in memory. Which is what you are asking for. >=20 > So, you're saying that I now need to write code like: > #if LITTLE_ENDIAN /* or how ever this is spelled*/ > var =3D le32enc(foo); > #else > var =3D be32enc(foo); > #endif >=20 > If I want to read a arch native endian value? No thank you=85 I=92m not saying that at all. >>> Also, only the enc/dec functions are documented to work on = non-aligned >>> address, so that doesn't help in most cases? >>=20 >> They work on all addresses. They are even documented to work on any = address: >>=20 >> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), = be64dec(), >> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and = le64dec() >> functions encode and decode integers to/from byte strings on any = align- >> ment in big/little endian format. >>=20 >> So they are quite useful in general. Peeking under the covers at the = implementation >> also shows they will work for any alignment, so I?m having trouble = understanding >> where this objection is really coming from. >=20 > There are places where you write code such as: > int i; > memcpy(&i, inp, sizeof i); > /* use i */ >=20 > In order to avoid alignment faults... None of the functions in = byteorder > do NO conversion of endian, or you have to know which endian you are = but > that doesn't work on MI code... >=20 > Did you read what the commited code did? No, I missed that bit beaded on your reply (which seemed to imply you = needed endian conversion) which implied the enc/dec are only documented to work = on non-aligned which is what I was correcting. But maybe the more basic question is why do you even have packed structures that are native endian that you want to access as naturally aligned structures? How did they become native endian and why weren=92t they converted to a more natural layout at that time? Warner --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzUBtAAoJEGwc0Sh9sBEAlpEP/0YBNPGJbxbgWHd3OwBOQEeG gH9ZQ4OJ9NDxUo0frRuLb6LRtZPBJ+iNS6GHnygnnSrdDqcTV6sV5+u1h0SGhQ8H oy3tC10rHTj3IRnqzTP+mdUb2wL4ztBWnRImkK16rAr7/mUY2BF06SLZLu9gkK4A FTq18IQS4jTG+NLLiTaBuGnv7jJj8m7LbkN3mtkylSIFecTRPFDjIr8x+S7dOTjJ hn45Z07Js62fiw8l+Wm1lSBNOgc1t9bVfSZvN19o05WGsDuIKwCZQQykEgiGKOFR B9jcgLhSxJyvwU+G7MYOVRZAe3uCBQ86AhzONoYcjWRTPsSRoYCgcfhbN69q/Cbo fssySrfTSqf+jE6JGDLyBCRg8SAPtY+INCHPvC3lOwcOy0ZwVBujBkttTxjOJhHE +QPqwNSlbuL0KGT4ybdROlBOyLdTLhfgPfH4J/PZqaj71Bal+O0ZHDDoDG7yA9Q2 CsRf3FEtkTJ2GlefkjlTQF5eMlKI7ebfFFenMdD5WDUMU6bfFGlUQ9sos0kahORK D0OqvKN09+aBNZ4Z3NDmG72TzGEoexnHBNPoShMf4t7Gq8Qq+Z3mZY3TON3e4+ba Jm2ZjANSO/G1WJXHHh1wY+Ji+G8jHTA9UkMFl6E/NVPYVP29JtJcu8i65QT4hZXS X4qVhGagEZic5iaTeSp3 =4kUJ -----END PGP SIGNATURE----- --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 16:56:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19697494; Mon, 21 Jul 2014 16:56:22 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD1EE2C4A; Mon, 21 Jul 2014 16:56:21 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6LGuJfZ041955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 09:56:20 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6LGuJhm041954; Mon, 21 Jul 2014 09:56:19 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Jul 2014 09:56:19 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140721165619.GT45513@funkthat.com> Mail-Followup-To: Warner Losh , Tim Kientzle , arch@freebsd.org, freebsd-arm , Fabien Thomas , Ian Lepore References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Jul 2014 09:56:20 -0700 (PDT) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:56:22 -0000 Warner Losh wrote this message on Mon, Jul 21, 2014 at 10:31 -0600: > > On Jul 21, 2014, at 10:25 AM, John-Mark Gurney wrote: > > > Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: > >> > >> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: > >> > >>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >>>> > >>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > >>>> > >>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >>>>>> Sorry to take so long to reply to this, I'm trying to get caught up. I > >>>>>> see you've already committed the mge fixes. I think the ELF alignment > >>>>>> fix looks good and should also be committed. > >>>>> > >>>>> So, re the elf alignment... > >>>>> > >>>>> I think we should get a set of macros that handle load/stores to/from > >>>>> unaligned addresses that are transparent to the caller.... I need > >>>>> these for some other code I'm writing... > >>>>> > >>>>> I thought Open/Net had these available, but I can't seem to find them > >>>>> right now... > >>>> > >>>> $ man 9 byteorder > >>>> > >>>> is most of what you want, lacking only some aliases to pick > >>>> the correct macro for native byte order. > >>> > >>> Um, those doesn't help if you want native endian order? > >> > >> Ummm, yes they do. enc converts from native order. dec decodes to native byte > > > > No they don't.. If you want to read a value in memory that is native > > endian order to native endian order (no conversion), they cannot be > > used w/o using something like below? > > Missed the native to native. bcopy works, but is ugly, as you note below. > > >> order. They are more general cases than the ntoh* functions that are more traditional > >> since they also work on byte streams that may not be completely aligned when > >> sitting in memory. Which is what you are asking for. > > > > So, you're saying that I now need to write code like: > > #if LITTLE_ENDIAN /* or how ever this is spelled*/ > > var = le32enc(foo); > > #else > > var = be32enc(foo); > > #endif > > > > If I want to read a arch native endian value? No thank you? > > I?m not saying that at all. > > >>> Also, only the enc/dec functions are documented to work on non-aligned > >>> address, so that doesn't help in most cases? > >> > >> They work on all addresses. They are even documented to work on any address: > >> > >> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec(), > >> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec() > >> functions encode and decode integers to/from byte strings on any align- > >> ment in big/little endian format. > >> > >> So they are quite useful in general. Peeking under the covers at the implementation > >> also shows they will work for any alignment, so I?m having trouble understanding > >> where this objection is really coming from. > > > > There are places where you write code such as: > > int i; > > memcpy(&i, inp, sizeof i); > > /* use i */ > > > > In order to avoid alignment faults... None of the functions in byteorder > > do NO conversion of endian, or you have to know which endian you are but > > that doesn't work on MI code... > > > > Did you read what the commited code did? > > No, I missed that bit beaded on your reply (which seemed to imply you needed > endian conversion) which implied the enc/dec are only documented to work on non-aligned > which is what I was correcting. Hmm... It appears that byteorder(9) leaks to userland though isn't documented to be available in userland... Should we fix this and make it an offical userland API? How to document it? In my case, the enc/dec version would have been enough for what I need, but not "part of the userland API"... There is an xref from byteorder(3), but no comment on either that they will work.. > But maybe the more basic question is why do you even have packed > structures that are native endian that you want to access as naturally > aligned structures? How did they become native endian and why weren?t > they converted to a more natural layout at that time? The original message said why... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 17:16:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 153D5B82 for ; Mon, 21 Jul 2014 17:16:41 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C50EF2E41 for ; Mon, 21 Jul 2014 17:16:40 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so7081822iec.38 for ; Mon, 21 Jul 2014 10:16:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2vnYV1OwPZU48U6RQgSDbsqe/S1b9OH1hRT5ZR2Sr6Q=; b=UQykxDQvo+4BraihfTHVeUvzQLUy3KISB0zj7fj3k4O0Ae9gBH5KF5gW0Y3vNPqnFW r+Imyjxkgw3LukTIoK/SxcTOMtPAiKC3RF7rSjfudGg67H2WJi8byGG3eNHsHdzumfb+ LYSHvjIkKk0Zq849h2fpaCCNpeT/tDj3KoYcdsm3nTm0QxhisRcb6l4Kg9PJXS7na5Nz b2UmCWRm7i2rBXutF8YUGSSpbW9zDUV9g5GIXch8P2KH230aASMPV/eBmfFXuxC/3HNV LJNXZOGGjHJZozXAK3LuYo0g5fO1p7xoYBMmeibWxHo8GIL+OIUqEFxD0GysRmhzDBOL oofQ== X-Gm-Message-State: ALoCoQleayPd8UTv9oslVucrmychARuE7BeC1klGbIM9B5XoMdFzGQsgUp5vBJFXrud/v+z+UnUI X-Received: by 10.50.80.116 with SMTP id q20mr7508438igx.22.1405962999843; Mon, 21 Jul 2014 10:16:39 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id dx6sm40361495igb.15.2014.07.21.10.16.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 10:16:38 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_0BBD206C-C6E0-434F-B718-ABB5CFD259E3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Warner Losh In-Reply-To: <20140721165619.GT45513@funkthat.com> Date: Mon, 21 Jul 2014 11:16:37 -0600 Message-Id: References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> <20140721165619.GT45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:16:41 -0000 --Apple-Mail=_0BBD206C-C6E0-434F-B718-ABB5CFD259E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 21, 2014, at 10:56 AM, John-Mark Gurney wrote: > Warner Losh wrote this message on Mon, Jul 21, 2014 at 10:31 -0600: >>=20 >> On Jul 21, 2014, at 10:25 AM, John-Mark Gurney = wrote: >>=20 >>> Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: >>>>=20 >>>> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney = wrote: >>>>=20 >>>>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 = -0700: >>>>>>=20 >>>>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: >>>>>>=20 >>>>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 = -0600: >>>>>>>> Sorry to take so long to reply to this, I'm trying to get = caught up. I >>>>>>>> see you've already committed the mge fixes. I think the ELF = alignment >>>>>>>> fix looks good and should also be committed. >>>>>>>=20 >>>>>>> So, re the elf alignment... >>>>>>>=20 >>>>>>> I think we should get a set of macros that handle load/stores = to/from >>>>>>> unaligned addresses that are transparent to the caller.... I = need >>>>>>> these for some other code I'm writing...=20 >>>>>>>=20 >>>>>>> I thought Open/Net had these available, but I can't seem to find = them >>>>>>> right now... >>>>>>=20 >>>>>> $ man 9 byteorder >>>>>>=20 >>>>>> is most of what you want, lacking only some aliases to pick >>>>>> the correct macro for native byte order. >>>>>=20 >>>>> Um, those doesn't help if you want native endian order? >>>>=20 >>>> Ummm, yes they do. enc converts from native order. dec decodes to = native byte >>>=20 >>> No they don't.. If you want to read a value in memory that is native >>> endian order to native endian order (no conversion), they cannot be >>> used w/o using something like below? >>=20 >> Missed the native to native. bcopy works, but is ugly, as you note = below. >>=20 >>>> order. They are more general cases than the ntoh* functions that = are more traditional >>>> since they also work on byte streams that may not be completely = aligned when >>>> sitting in memory. Which is what you are asking for. >>>=20 >>> So, you're saying that I now need to write code like: >>> #if LITTLE_ENDIAN /* or how ever this is spelled*/ >>> var =3D le32enc(foo); >>> #else >>> var =3D be32enc(foo); >>> #endif >>>=20 >>> If I want to read a arch native endian value? No thank you? >>=20 >> I?m not saying that at all. >>=20 >>>>> Also, only the enc/dec functions are documented to work on = non-aligned >>>>> address, so that doesn't help in most cases? >>>>=20 >>>> They work on all addresses. They are even documented to work on any = address: >>>>=20 >>>> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), = be64dec(), >>>> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and = le64dec() >>>> functions encode and decode integers to/from byte strings on any = align- >>>> ment in big/little endian format. >>>>=20 >>>> So they are quite useful in general. Peeking under the covers at = the implementation >>>> also shows they will work for any alignment, so I?m having trouble = understanding >>>> where this objection is really coming from. >>>=20 >>> There are places where you write code such as: >>> int i; >>> memcpy(&i, inp, sizeof i); >>> /* use i */ >>>=20 >>> In order to avoid alignment faults... None of the functions in = byteorder >>> do NO conversion of endian, or you have to know which endian you are = but >>> that doesn't work on MI code... >>>=20 >>> Did you read what the commited code did? >>=20 >> No, I missed that bit beaded on your reply (which seemed to imply you = needed >> endian conversion) which implied the enc/dec are only documented to = work on non-aligned >> which is what I was correcting. >=20 > Hmm... It appears that byteorder(9) leaks to userland though isn't > documented to be available in userland... Should we fix this and make > it an offical userland API? How to document it? In my case, the > enc/dec version would have been enough for what I need, but not "part = of > the userland API"... There is an xref from byteorder(3), but no > comment on either that they will work.. Yes. We should fix this now that it isn=92t confined to the kernel. >> But maybe the more basic question is why do you even have packed >> structures that are native endian that you want to access as = naturally >> aligned structures? How did they become native endian and why weren?t >> they converted to a more natural layout at that time? >=20 > The original message said why=85 I personally think the original code should unconditionally call = load_ptr() and store_ptr() and if the optimization for aligned access is actually worth doing, the = test for it should be in those functions rather than inline throughout the code. The code will = be clearer, and it would be easier to optimize those cases that actually matter. I=92m frankly surprised that these relocations are being generated = unaligned. Perhaps that=92s the real bug here that should be fixed. While I=92m OK with the original = patch (subject to the above), I=92d be curious what other cases there are for this = functionality. You had said that you had additional use cases in the network stack, but I=92m having = trouble groking the use cases. If this is a huge deal, then defining functions to do this is trivial. = I=92m just not sure it is common enough to need a special macro/function call in the base. Warner --Apple-Mail=_0BBD206C-C6E0-434F-B718-ABB5CFD259E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzUr1AAoJEGwc0Sh9sBEAl6MP+QGfnLxyKTIOrOuCgJ8ps7dW SewJMNsTNebtICWMUBe+SWZ7NDnKEr6M7T61o9wpdckc3n7K2XtrPrppiUHmDF79 Y+nXzJWAMAsDxyJ9Y8axXupV1WsA0xqQ4+VnHWx5wLCAjVkfejw3O5CqF9ljMVr2 jnyge07Kdrfd31Jz/WguuHuBp9E32wv4UCvYWUweRDdwKUmMW2oLMtdbo1beD3pH RLV4lKDMrjpoaiTc9VkaRBT97e4AJFHZQYvUqfb6T0PGQQb3I3cCAir96WbOwpBP NQR/kTg4zRdwsjSos99bwyEkLu1k9JHduEdCMpfB+Y7itff1aybnqFMZzRlNT9X1 ILYpOvvQBlI9QtjbtiEQV/ABGQtLr+R1yMHYqMk5SafAvrR3yQ48FpYFIimnGd2d IIoDZuJxt/yTiM/sXsHhxSDx3qWyfSspcYwuGwdRWiMeG+XDrXBoeoiC48eGMuwG 9jbb3FLNa8cZ3eMJlQn2GEIBBK9qttVBbZxLWK09V/e+fqL0htUzA8XadLrCZUSR uUYoZsgGefPDfty/H51PPSCiOSYABdBkYuUuUZzAsWTp8SXbD7apbyK1TztgkJ6I 7mLv7R0s7I1gWH2qqmn9dwDuEW8Auhku85xTc0XMm06NyQ7RqRcx4f4mX0fxRmOI jpMqP2vyWDtX4xNOsfUD =QDdl -----END PGP SIGNATURE----- --Apple-Mail=_0BBD206C-C6E0-434F-B718-ABB5CFD259E3-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 17:53:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D66EE8EF; Mon, 21 Jul 2014 17:53:21 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 8158B21F3; Mon, 21 Jul 2014 17:53:21 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id D809D10525BD; Tue, 22 Jul 2014 03:53:11 +1000 (EST) Date: Tue, 22 Jul 2014 03:53:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: [CFR] mge driver / elf reloc In-Reply-To: <1405955048.85788.74.camel@revolution.hippie.lan> Message-ID: <20140722022100.S2586@besplex.bde.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <1405955048.85788.74.camel@revolution.hippie.lan> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=eojmkOZX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=5zrNXb6StqYA:10 a=JzwRw_2MAAAA:8 a=nlC_4_pT8q9DhB4Ho9EA:9 a=cz2ZRIgtxKwA:10 a=wJWlkF7cXJYA:10 a=4FFUHJPBAAAA:8 a=SwFuXEZpslA4kWn8nBEA:9 a=nDTWHVfmmjYssBZ0:21 a=zWtDtkundl5VsItk:21 a=45ClL6m2LaAA:10 a=WglDhLyllLQA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: arch@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:53:22 -0000 On Mon, 21 Jul 2014, Ian Lepore wrote: > On Mon, 2014-07-21 at 08:46 -0600, Warner Losh wrote: >> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: >> >>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: >>>> >>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote= : >>>> >>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: >>>>>> Sorry to take so long to reply to this, I'm trying to get caught up.= I >>>>>> see you've already committed the mge fixes. I think the ELF alignme= nt >>>>>> fix looks good and should also be committed. >>>>> >>>>> So, re the elf alignment... >>>>> >>>>> I think we should get a set of macros that handle load/stores to/from >>>>> unaligned addresses that are transparent to the caller.... I need >>>>> these for some other code I'm writing... >>>>> >>>>> I thought Open/Net had these available, but I can't seem to find them >>>>> right now... >>>> >>>> $ man 9 byteorder >>>> >>>> is most of what you want, lacking only some aliases to pick >>>> the correct macro for native byte order. >>> >>> Um, those doesn't help if you want native endian order=85 >> >> Ummm, yes they do. enc converts from native order. dec decodes to native= byte >> order. They are more general cases than the ntoh* functions that are mor= e traditional >> since they also work on byte streams that may not be completely aligned = when >> sitting in memory. Which is what you are asking for. >> >>> Also, only the enc/dec functions are documented to work on non-aligned >>> address, so that doesn't help in most cases=85 >> >> They work on all addresses. They are even documented to work on any addr= ess: >> >> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec(= ), >> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec(= ) >> functions encode and decode integers to/from byte strings on any al= ign- >> ment in big/little endian format. >> >> So they are quite useful in general. Peeking under the covers at the imp= lementation >> also shows they will work for any alignment, so I=92m having trouble und= erstanding >> where this objection is really coming from. > > The functionality requested was alignment-safe copy/assign without any > endian change. The code in question was conceptually something like > > if (pointer & 0x03) > do-alignment-safe-thing > else > directly-deref-the-pointer The enc/dec functions could be pessimized like that, but are actually pessimized in other ways. Pessimizations in the above include conditional branches for the check and large code. Everything has to be inlined else it is much slower than direct dereference, but then it has scattered branches that may exhaust the branch prediction cache (if any) and large code that may exhaust other caches. The enc/dec functions don't have any branches, but they have large code like: % static __inline void % le32enc(void *pp, uint32_t u) % { % =09uint8_t *p =3D (uint8_t *)pp; %=20 % =09p[0] =3D u & 0xff; % =09p[1] =3D (u >> 8) & 0xff; % =09p[2] =3D (u >> 16) & 0xff; % =09p[3] =3D (u >> 24) & 0xff; % } Fastest on x86 (unless alignment check exceptions are enabled in CR0) is to just do the access and let the hardware combine the bytes. The accesses should probably be written someything like le32enc() above, but more carefully. Compilers should convert the above to a single 32-bit access on x86 (unless alignment check exceptions...). The pessimizations are that compilers aren't that smart, and/or the enc/dec functions are written in such a way that compilers are constrained from doing this. IIRC, clang does this for one direction only and gcc-4.2.1 is not smart enough to do this for either direction. IIRC, the problematic direction is the above one, where the value is returned indirectly. Sprinkling __restrict might help. When there is endianness conversion, there must be both an access (hopefully 32 bits) and swapping operation on a register, unless all the bytes are copied from memory to memory 1 or 2 at a time. clang is smart about converting the large expressions in __bswapNN_gen() into single bswap instructions if the original rvalue is in a register, but IIRC it is not so smart for the equivalent conversions written with bytes and indirections. (x86 and IIRC some other arches have the __bswapNN_gen() macros. These macros are just as MI as the enc/dec inlines and more carefully written but they have not been deduplicated due to namespace problems inhibiting a complete cleanup of the MD endian.h files.) Accesses are often pessimized using the __packed mistake. This bug is still uncommon in ipv4 headers, but is used with minimal damage in struct ip. struct ip is declared as __packed and __aligned(4). Here __aligned(4) tells that the struct aligned normally although it is packed. ipv6 headers ask for full pessimizations by declaring almost everything as __packed without __aligned(N). This tells the compiler that the struct might only be 1-byte aligned, so all accesses to it must be 1 byte at a time except on arches like x86 where the above optimization applies (the optimization is much easier to do when the accesses are not expressed bytewise in the code). Bytewise accesses are also less inherently atomic. I think there used to be a problem with __packed and __aligned() attributes not being inherited by function pointers, but can't fdind any problem now. ia64 code for loading an int from a __packed struct (p.x): % addl r16 =3D @ltoffx(p#), r1 % ;; % ld8.mov r16 =3D [r16], p# % ;; % mov r14 =3D r16 % ;; % ld1 r15 =3D [r14], 1 % ;; % ld1 r14 =3D [r14] % ;; % shl r14 =3D r14, 8 % ;; % or r14 =3D r15, r14 % adds r15 =3D 2, r16 % ;; % ld1 r15 =3D [r15] % ;; % shl r15 =3D r15, 16 % ;; % or r15 =3D r14, r15 % adds r16 =3D 3, r16 % ;; % ld1 r8 =3D [r16] % ;; % shl r8 =3D r8, 24 % ;; % or r8 =3D r15, r8 It seems to have 5 memory references. The enc/dec32 functions produce a similar mess on x86 when the compiler can't optimize them. This is with gcc. clang doesn't work on ia64 and/or pluto. ia64 code for loading an int from a __packed __aligned(4) struct (p.x): addl r14 =3D @ltoffx(p#), r1 ;; ld8.mov r14 =3D [r14], p# ;; ld4 r8 =3D [r14] This behaviour can probable be exploited in the enc/dec functions. When there is no endianness conversion, write 32-bit accesses as p->x where p is a pointer to a __packed __aligned(1) struct containing x. The compiler will then produce the above mess on ia64 and a single 32-bit access if possible. No ifdefs required. When there is an endianess conversion, do it on a register with value p->x. Lightly tested implementation: % struct _le32 { % =09uint32_t _x; % } __packed; %=20 % #define=09le32enc(p, u)=09(((struct _le32 *)(p))->_x =3D (u)) This is simpler than the inline version, and fixes some namespace errors. If you want avoid the mess on ia64, this can be done at compile time if the alignment is known to be more than 1 then. I think if can often be known, as for struct ip (don't generate misaligned struct ip, and if you start with one then copy to an aligned one). The enc/dec inline functions could handle this by being converted to macros that take the alignment parameter. If the alignment is not known until runtime...don't do that. To add an alignment parameter to the above, use something like: #define=09_sle32(a)=09struct _le32 { uint32_t _x; } __packed __aligned(a) #define=09le32enc(p, u, a)=09(((_sle32(a) *)(p))->_x =3D (u)) Macroizing the struct declaration to add the alignment parameter to it and avoiding backslashes made the code less readable but even shorter. This was tested on i386 and ia64 with alignments 1 and 4 and and gave the expected output in asm. Bruce From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 18:28:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58A3F2AB; Mon, 21 Jul 2014 18:28:22 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 140C624C6; Mon, 21 Jul 2014 18:28:21 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X9IJv-000FsY-QT; Mon, 21 Jul 2014 18:28:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6LISIeP033020; Mon, 21 Jul 2014 12:28:18 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/IbHu2Ip3HrQmS1MVVZC3X X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] mge driver / elf reloc From: Ian Lepore To: Warner Losh In-Reply-To: References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> <20140721165619.GT45513@funkthat.com> Content-Type: text/plain; charset="windows-1251" Date: Mon, 21 Jul 2014 12:28:17 -0600 Message-ID: <1405967297.85788.78.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s6LISIeP033020 Cc: arch@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:28:22 -0000 On Mon, 2014-07-21 at 11:16 -0600, Warner Losh wrote: > On Jul 21, 2014, at 10:56 AM, John-Mark Gurney wrote= : >=20 > > Warner Losh wrote this message on Mon, Jul 21, 2014 at 10:31 -0600: > >>=20 > >> On Jul 21, 2014, at 10:25 AM, John-Mark Gurney wr= ote: > >>=20 > >>> Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: > >>>>=20 > >>>> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney w= rote: > >>>>=20 > >>>>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -07= 00: > >>>>>>=20 > >>>>>> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney = wrote: > >>>>>>=20 > >>>>>>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -06= 00: > >>>>>>>> Sorry to take so long to reply to this, I'm trying to get caug= ht up. I > >>>>>>>> see you've already committed the mge fixes. I think the ELF a= lignment > >>>>>>>> fix looks good and should also be committed. > >>>>>>>=20 > >>>>>>> So, re the elf alignment... > >>>>>>>=20 > >>>>>>> I think we should get a set of macros that handle load/stores t= o/from > >>>>>>> unaligned addresses that are transparent to the caller.... I n= eed > >>>>>>> these for some other code I'm writing...=20 > >>>>>>>=20 > >>>>>>> I thought Open/Net had these available, but I can't seem to fin= d them > >>>>>>> right now... > >>>>>>=20 > >>>>>> $ man 9 byteorder > >>>>>>=20 > >>>>>> is most of what you want, lacking only some aliases to pick > >>>>>> the correct macro for native byte order. > >>>>>=20 > >>>>> Um, those doesn't help if you want native endian order? > >>>>=20 > >>>> Ummm, yes they do. enc converts from native order. dec decodes to = native byte > >>>=20 > >>> No they don't.. If you want to read a value in memory that is nativ= e > >>> endian order to native endian order (no conversion), they cannot be > >>> used w/o using something like below? > >>=20 > >> Missed the native to native. bcopy works, but is ugly, as you note b= elow. > >>=20 > >>>> order. They are more general cases than the ntoh* functions that a= re more traditional > >>>> since they also work on byte streams that may not be completely al= igned when > >>>> sitting in memory. Which is what you are asking for. > >>>=20 > >>> So, you're saying that I now need to write code like: > >>> #if LITTLE_ENDIAN /* or how ever this is spelled*/ > >>> var =3D le32enc(foo); > >>> #else > >>> var =3D be32enc(foo); > >>> #endif > >>>=20 > >>> If I want to read a arch native endian value? No thank you? > >>=20 > >> I?m not saying that at all. > >>=20 > >>>>> Also, only the enc/dec functions are documented to work on non-al= igned > >>>>> address, so that doesn't help in most cases? > >>>>=20 > >>>> They work on all addresses. They are even documented to work on an= y address: > >>>>=20 > >>>> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64= dec(), > >>>> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64= dec() > >>>> functions encode and decode integers to/from byte strings on an= y align- > >>>> ment in big/little endian format. > >>>>=20 > >>>> So they are quite useful in general. Peeking under the covers at t= he implementation > >>>> also shows they will work for any alignment, so I?m having trouble= understanding > >>>> where this objection is really coming from. > >>>=20 > >>> There are places where you write code such as: > >>> int i; > >>> memcpy(&i, inp, sizeof i); > >>> /* use i */ > >>>=20 > >>> In order to avoid alignment faults... None of the functions in byt= eorder > >>> do NO conversion of endian, or you have to know which endian you ar= e but > >>> that doesn't work on MI code... > >>>=20 > >>> Did you read what the commited code did? > >>=20 > >> No, I missed that bit beaded on your reply (which seemed to imply yo= u needed > >> endian conversion) which implied the enc/dec are only documented to = work on non-aligned > >> which is what I was correcting. > >=20 > > Hmm... It appears that byteorder(9) leaks to userland though isn't > > documented to be available in userland... Should we fix this and mak= e > > it an offical userland API? How to document it? In my case, the > > enc/dec version would have been enough for what I need, but not "part= of > > the userland API"... There is an xref from byteorder(3), but no > > comment on either that they will work.. >=20 > Yes. We should fix this now that it isn=92t confined to the kernel. >=20 > >> But maybe the more basic question is why do you even have packed > >> structures that are native endian that you want to access as natural= ly > >> aligned structures? How did they become native endian and why weren?= t > >> they converted to a more natural layout at that time? > >=20 > > The original message said why=85 >=20 > I personally think the original code should unconditionally call load_p= tr() and store_ptr() > and if the optimization for aligned access is actually worth doing, the= test for it should be > in those functions rather than inline throughout the code. The code wil= l be clearer, and > it would be easier to optimize those cases that actually matter. >=20 > I=92m frankly surprised that these relocations are being generated unal= igned. Perhaps that=92s > the real bug here that should be fixed. While I=92m OK with the origina= l patch (subject to the > above), I=92d be curious what other cases there are for this functional= ity. You had said that > you had additional use cases in the network stack, but I=92m having tro= uble groking the > use cases. >=20 > If this is a huge deal, then defining functions to do this is trivial. = I=92m just not sure it is common > enough to need a special macro/function call in the base. >=20 > Warner >=20 I was trying to figure out how unaligned relocs even happen, and I think one possibility would be something like this... char thing[] =3D "x"; struct { char x; char *something; } __packed foo =3D {'a', thing}; Which seems contrived enough that I wonder how it happens in real life. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 18:32:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 017C468B for ; Mon, 21 Jul 2014 18:32:06 +0000 (UTC) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56B9E2570 for ; Mon, 21 Jul 2014 18:32:04 +0000 (UTC) Received: from mail-wg0-f42.google.com ([74.125.82.42]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKU81cnQn4dYeII7zN7ezdcazBkgFkHRqy@postini.com; Mon, 21 Jul 2014 18:32:05 UTC Received: by mail-wg0-f42.google.com with SMTP id l18so6712141wgh.1 for ; Mon, 21 Jul 2014 11:31:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=U5St3ArwFbPcjsLhAQwS5K7bRIWZ39/QJiN+QiJYB/U=; b=WsClsrXCk4KEvrimwx9sRVFpnhmGErqRQt+hPhfnCYl4xjRKYIR1HhX+iGS8w/pPPg wCKPptgbNbIPw7Zoo0RP2IKX4vCnQyPfLuZLFw02enjcvzry5PcdXqfDHkKlXMQt+IKx iUwNztHeJyoyixZg2ZYm9JE9akbuInJG5PohkpqPKedeqkjFtdXnY99f3OQyKCn3IDxx X9RIa8k+mxpO7Anb76DJWXMcMS76Fm2e6u1dg2ij6mD3kmg8OBgCeSygVtOVGzhfl36r n4b/dlTytt5B+2Hhh/uoonLBVVYmFW4gvSCSM13uYurpVwUidVEM/IifxzYFTLtVlJhq NxCA== X-Received: by 10.194.22.201 with SMTP id g9mr25498802wjf.98.1405967082887; Mon, 21 Jul 2014 11:24:42 -0700 (PDT) X-Gm-Message-State: ALoCoQk/n2VKBEt8UMkIL6rF3bvecM1S3SEITVSD7nXjbR8c6EDi6rr9rfUdR3CPOjH4GnkbiiQicX92nu+S28yXhuNtQc7nCVxiKGQw0exAeI8XnmNv2qPJpHxnxdsRZw81Fc2luFS4 X-Received: by 10.194.22.201 with SMTP id g9mr25498741wjf.98.1405967082458; Mon, 21 Jul 2014 11:24:42 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id n8sm44558147wia.19.2014.07.21.11.24.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jul 2014 11:24:41 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6LIOeWF072662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Jul 2014 19:24:40 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6LIOebl072661 for freebsd-arm@freebsd.org; Mon, 21 Jul 2014 19:24:40 +0100 (BST) (envelope-from mexas) Date: Mon, 21 Jul 2014 19:24:40 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407211824.s6LIOebl072661@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: graphics/libdrm install errors Reply-To: mexas@bris.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:32:06 -0000 Anybody else is seeing this: ===> Installing for libdrm-2.4.54 ===> Checking if graphics/libdrm already installed ===> Registering installation for libdrm-2.4.54 as automatic pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/include/libms/libkms.h): No such file or directory pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/lib/libkms.o): No such file or directory pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/lib/libkms.o.1): No such file or directory pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/lib/libkms.o.1.0.0): No such file or directory pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/libdata/pkgonfig/libkms.pc): No such file or directory pkg-static: lstat(/usr/ports/graphics/libdrm/work/stage/usr/local/include/libms/): No such file or directory *** Error code 74 # uname -a FreeBSD BOZO 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 19:27:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF3F7857; Mon, 21 Jul 2014 19:27:41 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 89B1A2A79; Mon, 21 Jul 2014 19:27:40 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 3D6A1789EA1; Tue, 22 Jul 2014 05:27:38 +1000 (EST) Date: Tue, 22 Jul 2014 05:27:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh Subject: Re: [CFR] mge driver / elf reloc In-Reply-To: <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> Message-ID: <20140722041517.M3229@besplex.bde.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=dZS5gxne c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=5zrNXb6StqYA:10 a=JzwRw_2MAAAA:8 a=nlC_4_pT8q9DhB4Ho9EA:9 a=cz2ZRIgtxKwA:10 a=wJWlkF7cXJYA:10 a=4FFUHJPBAAAA:8 a=YqLNQ_TDFebG-c2cgr8A:9 a=vXiuCQx8rN4fGCkZ:21 a=tLJyy6OA8_LDPdHi:21 a=45ClL6m2LaAA:10 a=WglDhLyllLQA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Tim Kientzle , Ian Lepore , arch@freebsd.org, freebsd-arm , Fabien Thomas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:27:42 -0000 On Mon, 21 Jul 2014, Warner Losh wrote: > On Jul 21, 2014, at 10:25 AM, John-Mark Gurney wrote: > >> Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: >>> >>> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: >>> >>>> Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: >>>>> $ man 9 byteorder >>>>> >>>>> is most of what you want, lacking only some aliases to pick >>>>> the correct macro for native byte order. >>>> >>>> Um, those doesn't help if you want native endian order? >>> >>> Ummm, yes they do. enc converts from native order. dec decodes to nativ= e byte >> >> No they don't.. If you want to read a value in memory that is native >> endian order to native endian order (no conversion), they cannot be >> used w/o using something like below=85 > > Missed the native to native. bcopy works, but is ugly, as you note below. Indeed, the API is missing support for the easy case of host load/store. But this is a feature. He used memcpy(), not bcopy(). This is a case where using memcpy() instead of bcopy() is not a style bug. Using memcpy() is pretty. >>> order. They are more general cases than the ntoh* functions that are mo= re traditional >>> since they also work on byte streams that may not be completely aligned= when >>> sitting in memory. Which is what you are asking for. >> >> So, you're saying that I now need to write code like: >> #if LITTLE_ENDIAN /* or how ever this is spelled*/ >> =09var =3D le32enc(foo); >> #else >> =09var =3D be32enc(foo); >> #endif >> >> If I want to read a arch native endian value? No thank you=85 > > I=92m not saying that at all. > >>>> Also, only the enc/dec functions are documented to work on non-aligned >>>> address, so that doesn't help in most cases? >>> >>> They work on all addresses. They are even documented to work on any add= ress: >>> >>> The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec(= ), >>> le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec(= ) >>> functions encode and decode integers to/from byte strings on any al= ign- >>> ment in big/little endian format. >>> >>> So they are quite useful in general. Peeking under the covers at the im= plementation >>> also shows they will work for any alignment, so I?m having trouble unde= rstanding >>> where this objection is really coming from. >> >> There are places where you write code such as: >> =09int i; >> =09memcpy(&i, inp, sizeof i); >> =09/* use i */ >> >> In order to avoid alignment faults... None of the functions in byteorde= r >> do NO conversion of endian, or you have to know which endian you are but >> that doesn't work on MI code... This is good code. memcpy() is likely to be optimized better than anything in . Even with the optimizations in my previous reply. Compilers do magic things with memcpy(), like turning it into a no-op if the memory is already in a register and the register doesn't need to be moved. Sometimes the register needs to be moved but the move can be, and is, to another register (perhaps in a different register set, like XMM instead of a general register on x86). Doing nothing much for memcpy()s that are just for a alignment is a special case of this. For the above, on all arches, the compiler should load the int-sized memory at address inp into an int-sized register and then rename the register to i (i should never hit memory unless it is changed and the change needs to be stored). The instructions that are used for the load depend on what the compiler knows about the alignment of inp, and the alignment requirements of the arch. On arches without strict alignment, like x86 without CR0_AC, there is nothing better than doing a mislaligned load *(int *)inp the same as you could do by lieing to the compiler. On arches with strict alignment, there is nothing better than loading 1 byte at a time and combining if the alignment of inp is 1 or unknown. This seems to make most of byteorder(9) a mistake. Just about everything can be done better using memcpy() and standard functions in byteorder(3), except the (3) functions only go up to 32 bits and have 1980's spellings [sl] for the integer sizes. All alignment stuff can be done in host order using memcpy(). Most byte swapping stuff can be done using ntohl(). The direction for n/h can be confusing but might need fewer ifdefs than be/le. le32enc done using more-standard APIs: first htole32() in a register. Only in byteorder(9) then store to an aligned uint32_t temporary variable (optimized away) then memcpy() to final place le32dec done using more-standard APIs: first memcpy() to aligned uint32_t temporary variable (optimized away) then load to a register then le32toh on a register. Only in byteorder(9) These take 1 line extra each (for the memcpy()). You already have to do this for h/l conversions. E.g.: htonl to from register to misaligned memory (like le32enc): first htonl() in the register. Standard in byteorder(3) and POSIX. then store to an aligned uint32_t temporary variable (optimized away) then memcpy() to final place -fbuiltin is essential for optimizing memcpy(), so memcpy must be spelled __builtin_memcpy in time-critical code if -fbuiltin might be turned off. -fbuiltin used to be only turned off in the kernel for LINT, but this was broken 13 years ago by using -ffreestanding. 13 years is not long enough for LINT (conf/NOTES) to have caught up with the change. clang breaks this even more. With gcc, you can use -fbuiltin after -ffreestanding to turn builtins back on, but with clang -ffreestanding has apparently has precedence so -fbuiltin never turns builtins back on. Also, gcc's man page actually documents these options, and somewhere in the gcc documentation there is a recommendation to keep -fbuiltin off and only use selected builtins via __builtin_foo. Turning all builtins back on originally only caused minor problems with a few builtins like the one for printf. Bruce From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 19:55:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 870E12E3; Mon, 21 Jul 2014 19:55:35 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 184C52D2D; Mon, 21 Jul 2014 19:55:34 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 874907857FB; Tue, 22 Jul 2014 05:55:31 +1000 (EST) Date: Tue, 22 Jul 2014 05:55:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans Subject: Re: [CFR] mge driver / elf reloc In-Reply-To: <20140722022100.S2586@besplex.bde.org> Message-ID: <20140722053651.V3446@besplex.bde.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <1405955048.85788.74.camel@revolution.hippie.lan> <20140722022100.S2586@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=dZS5gxne c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=5zrNXb6StqYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=VRqNOJ3i96_1dxBxEUkA:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org, freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:55:35 -0000 On Tue, 22 Jul 2014, Bruce Evans wrote: > ... > This behaviour can probable be exploited in the enc/dec functions. > When there is no endianness conversion, write 32-bit accesses as > p->x where p is a pointer to a __packed __aligned(1) struct containing > x. The compiler will then produce the above mess on ia64 and a single > 32-bit access if possible. No ifdefs required. When there is an > endianess conversion, do it on a register with value p->x. > > Lightly tested implementation: > > % struct _le32 { > % uint32_t _x; > % } __packed; > % % #define le32enc(p, u) (((struct _le32 *)(p))->_x = (u)) > > This is simpler than the inline version, and fixes some namespace errors. Oops, that is not so good. I just rememembed another optimization that at least clang does in at least some cases for the inline version: if the the compiler can see that the pointer is to aligned memory (which it can sometimes do since the function is inline), then the compiler generates 1 32-bit access. The __packed attribute in the above defeats this by forcing to 1-byte alignment. > If you want avoid the mess on ia64, this can be done at compile time if > the alignment is known to be more than 1 then. I think if can often > be known, as for struct ip (don't generate misaligned struct ip, and > if you start with one then copy to an aligned one). The enc/dec > inline functions could handle this by being converted to macros that > take the alignment parameter. If the alignment is not known until > runtime...don't do that. > > To add an alignment parameter to the above, use something like: > > #define _sle32(a) struct _le32 { uint32_t _x; } __packed __aligned(a) > #define le32enc(p, u, a) (((_sle32(a) *)(p))->_x = (u)) > > Macroizing the struct declaration to add the alignment parameter to it > and avoiding backslashes made the code less readable but even shorter. > > This was tested on i386 and ia64 with alignments 1 and 4 and and gave > the expected output in asm. Also not so good. If the pointer was 'a'-byte aligned, then the 'a' parameter recovers by tells the compiler this in a worse way after __packed clobbers the original alignment. It is better for the caller to do any alignment. In other replies, we discussed using memcpy() to force alignment. The above macros could use it to copy to aligned memory and load as if from that memory less hackishly. This would work in the inline functions, but doesn't do a lot that the compiler can't already do. It is still better for callers to do any alignment. They can use memcpy(), or if they know that the pointer is n-byte aligned then they can cast the pointer an __aligned(n) one where the inline fnction can see the cast. The original pointer type might be void * or char * so memcpy() for alignment would have to copy memory, but _aligned(n) would be virtual. Bruce From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 20:11:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF2D9A4D; Mon, 21 Jul 2014 20:11:47 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5312EC9; Mon, 21 Jul 2014 20:11:47 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8F4331578; Mon, 21 Jul 2014 20:04:46 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s6LK4hPp038241; Mon, 21 Jul 2014 20:04:44 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans Subject: Re: [CFR] mge driver / elf reloc In-reply-to: <20140722041517.M3229@besplex.bde.org> From: "Poul-Henning Kamp" References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> <20140722041517.M3229@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38239.1405973083.1@critter.freebsd.dk> Date: Mon, 21 Jul 2014 20:04:43 +0000 Message-ID: <38240.1405973083@critter.freebsd.dk> Cc: Tim Kientzle , Ian Lepore , arch@freebsd.org, freebsd-arm , Fabien Thomas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:11:48 -0000 In message <20140722041517.M3229@besplex.bde.org>, Bruce Evans writes: >This seems to make most of byteorder(9) a mistake. Just about everything >can be done better using memcpy() and standard functions in byteorder(3), Covered by Bruce' "just about" is that code analysers like Coverity and FlexeLint cannot see through his proposed version of the macros on little-endian architectures because of the inline assembler used to access the exchange instructions which the C-compiler do not expose. Analysers have no such problems with the pure-C versions there today. The real fault is with the ISO-C people who still lives in a world where endianess doesn't exist. If they had done their job sensibly, variables, including members of structs, could be declared as having a specific storage-layout. My theory is that they confident the PDP-10 and CRAY-1 are just about to make a comeback... -- 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. From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 22:18:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB697BFC; Mon, 21 Jul 2014 22:18:29 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5732AC0; Mon, 21 Jul 2014 22:18:28 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id 04CF61A2E38; Tue, 22 Jul 2014 08:18:19 +1000 (EST) Date: Tue, 22 Jul 2014 08:18:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: [CFR] mge driver / elf reloc In-Reply-To: <38240.1405973083@critter.freebsd.dk> Message-ID: <20140722065334.D3681@besplex.bde.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> <20140722041517.M3229@besplex.bde.org> <38240.1405973083@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=eojmkOZX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=5zrNXb6StqYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=wuhp96_2kGOEJxqg69kA:9 a=CjuIK1q_8ugA:10 Cc: Tim Kientzle , Ian Lepore , arch@freebsd.org, freebsd-arm , Bruce Evans , Fabien Thomas X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:18:30 -0000 On Mon, 21 Jul 2014, Poul-Henning Kamp wrote: > In message <20140722041517.M3229@besplex.bde.org>, Bruce Evans writes: > >> This seems to make most of byteorder(9) a mistake. Just about everything >> can be done better using memcpy() and standard functions in byteorder(3), > > Covered by Bruce' "just about" is that code analysers like Coverity > and FlexeLint cannot see through his proposed version of the macros > on little-endian architectures because of the inline assembler used > to access the exchange instructions which the C-compiler do not expose. Not a problem: - byteorder(9) already uses the bswap macros in many cases (including for all conversions to and from big-endian on little-endian hosts) - we removed the pure exchange instructions from the x86 bswap16() macro some time ago - we still use inline asm and bswap instructions in it for the x86 bswap32() and bswap64(), but this is just to avoid pessimizing for gcc or ifdefs to do it only for gcc. clang doesn't need any asms. - maybe code analyzers don't understand the __packed that I used. That would be either a bug in the analysers or just another unportability in __packed. > Analysers have no such problems with the pure-C versions there today. Further checking on pluto shows that gcc pessimizes all cases in le32dec() and le32enc(). It forgets the alignment of variables in the caller when pointers to them are passed as void *, even though the function are inline. On little-endian arches like ia64, these functions do no byte swapping so they are equivalent to memcpy() (after loading or storing the non-memory parameter to memory) Here they are using _builtin_memcpy(), with namespace bugs fixed: static __inline uint32_t le32dec(const void *_p) { uint32_t _t; __builtin_memcpy(&_t, _p, sizeof(_t)); return (_t); } static __inline void le32enc(void *_p, uint32_t _u) { __builtin_memcpy(_p, &_u, sizeof(_u)); } gcc optimizes these as well as possible. It now sees alignment in the caller. The above assumes a little-endian host. I think adding htole32()'s makes it work for all hosts. This involves ifdefs, but the ifdefs are already there to select htole32(). Hopefully this remains optimal when htole32() is nontrivial. It is probably just a missing optimization that old gcc doesn't see the alignment in the caller for non-builtins too, but the above is also simpler. It moves most expressions to the nontrivial htole32(), etc. For other sizes, s/32/64/, etc. No need for shifts and masks. These are now in htole32(), etc., or implicit in memcpy(). For other endiannesses, s/le/be/. No need to reverse the expressions. The reversal is in htobe32(), etc. Bruce From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 23:31:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACDBD8CE; Mon, 21 Jul 2014 23:31:08 +0000 (UTC) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3DF211B; Mon, 21 Jul 2014 23:31:07 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 93D155607F; Mon, 21 Jul 2014 18:31:06 -0500 (CDT) Date: Mon, 21 Jul 2014 18:31:06 -0500 From: Mark Linimon To: Bruce Evans Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140721233106.GA17346@lonesome.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <1405955048.85788.74.camel@revolution.hippie.lan> <20140722022100.S2586@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140722022100.S2586@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 23:31:08 -0000 On Tue, Jul 22, 2014 at 03:53:10AM +1000, Bruce Evans wrote: > This is with gcc. clang doesn't work on ia64 and/or pluto. Since Marcel has dropped support for ia64, and in fact removed ia64- specific code from -HEAD, I'm not sure how much good this analysis will accomplish :-) mcl From owner-freebsd-arm@FreeBSD.ORG Tue Jul 22 07:16:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C282774; Tue, 22 Jul 2014 07:16:27 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 2075D24DE; Tue, 22 Jul 2014 07:16:26 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id A59C410E2951; Tue, 22 Jul 2014 17:16:09 +1000 (EST) Date: Tue, 22 Jul 2014 17:16:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Linimon Subject: Re: [CFR] mge driver / elf reloc In-Reply-To: <20140721233106.GA17346@lonesome.com> Message-ID: <20140722161501.K865@besplex.bde.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <1405955048.85788.74.camel@revolution.hippie.lan> <20140722022100.S2586@besplex.bde.org> <20140721233106.GA17346@lonesome.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=eojmkOZX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=5zrNXb6StqYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=hmZ8BYfCJ5Q0rm1RuK8A:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org, freebsd-arm , Ian Lepore , Bruce Evans X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 07:16:27 -0000 On Mon, 21 Jul 2014, Mark Linimon wrote: > On Tue, Jul 22, 2014 at 03:53:10AM +1000, Bruce Evans wrote: >> This is with gcc. clang doesn't work on ia64 and/or pluto. > > Since Marcel has dropped support for ia64, and in fact removed ia64- > specific code from -HEAD, I'm not sure how much good this analysis > will accomplish :-) ia64/pluto is just an example of an arch with strict alignment requirements. clang is broken for it so I could only test with gcc. This analysis applies to all non-x86 arches in FreeBSD cluster machines, since there aren't many others and the only other one (sparc64/flame) also has strict alignment requirements. clang is broken on it too, so I could only test with gcc: % #include % % struct foo { % int x; % } __packed; % % struct foo x; % % static __inline uint32_t % xle32dec(const void *_p) % { % uint32_t _t; % % __builtin_memcpy(&_t, _p, sizeof(_t)); % return (_t); % } % % static __inline void % xle32enc(void *_p, uint32_t _u) % { % % __builtin_memcpy(_p, &_u, sizeof(_u)); % } % % uint32_t % q(void) % { % return xle32dec(&x); % } % % void % r(void) % { % return xle32enc(&x, 1); % } This tests the memcpy versions. __packed gives the expected mess: % % .file "z.c" % .section ".text" % .align 4 % .align 32 % .global r % .type r, #function % .proc 020 % r: % .register %g2, #scratch % .register %g3, #scratch % add %sp, -208, %sp % mov 1, %g1 % st %g1, [%sp+2235] % sethi %hi(x), %g2 % or %g2, %lo(x), %g3 % ldub [%sp+2235], %g1 % stb %g1, [%g2+%lo(x)] % ldub [%sp+2236], %g1 % stb %g1, [%g3+1] % ldub [%sp+2237], %g1 % stb %g1, [%g3+2] % ldub [%sp+2238], %g1 % stb %g1, [%g3+3] % jmp %o7+8 % sub %sp, -208, %sp % .size r, .-r % .align 4 % .align 32 % .global q % .type q, #function % .proc 016 % q: % add %sp, -208, %sp % sethi %hi(x), %g1 % or %g1, %lo(x), %g2 % ldub [%g1+%lo(x)], %g1 % stb %g1, [%sp+2235] % ldub [%g2+1], %g1 % stb %g1, [%sp+2236] % ldub [%g2+2], %g1 % stb %g1, [%sp+2237] % ldub [%g2+3], %g1 % stb %g1, [%sp+2238] % lduw [%sp+2235], %o0 % jmp %o7+8 % sub %sp, -208, %sp % .size q, .-q % .common x,4,1 % .ident "GCC: (GNU) 4.2.1 20070831 patched [FreeBSD]" I think both functions copy the memory bytewise (4+4 memory references) and do 1 load of the final copy or 1 store to the temporary copy. So the memcpy is not virtual, and the memcpy versions might be worse than the -current versions which should use 4+1 memory references plus lots of shifts and masks on a registers. Register operations are faster but there are many more of them. Removing __packed gives the expected direct accesses: % .file "z.c" % .section ".text" % .align 4 % .align 32 % .global r % .type r, #function % .proc 020 % r: % .register %g2, #scratch % add %sp, -208, %sp % mov 1, %g2 % sethi %hi(x), %g1 % st %g2, [%g1+%lo(x)] % jmp %o7+8 % sub %sp, -208, %sp % .size r, .-r % .align 4 % .align 32 % .global q % .type q, #function % .proc 016 % q: % add %sp, -208, %sp % sethi %hi(x), %g1 % lduw [%g1+%lo(x)], %o0 % jmp %o7+8 % sub %sp, -208, %sp % .size q, .-q % .common x,4,4 % .ident "GCC: (GNU) 4.2.1 20070831 patched [FreeBSD]" The memcpy's seem to be virtual now. Maybe the compiler is avoiding the shifts and masks for the packed case intentionally. Timing tests on flame and pluto showed some problems. The memcpy versions are mostly faster in the non-__packed case and slower in the __packed case. This is as expected. The above case where the compiler virtulalize the memcpy is especially slow, as expected, but there are some other slow cases, an lots of differences between flame and pluto. The __packed case is 4-20 times slower. Bruce From owner-freebsd-arm@FreeBSD.ORG Tue Jul 22 07:38:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB5F9B52; Tue, 22 Jul 2014 07:38:00 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 606A62679; Tue, 22 Jul 2014 07:37:59 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id BBE962700B44; Tue, 22 Jul 2014 09:37:57 +0200 (CEST) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id A136D2700A68; Tue, 22 Jul 2014 09:37:57 +0200 (CEST) Received: from [10.2.1.1] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id 43C282700B44; Tue, 22 Jul 2014 09:37:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Fabien Thomas In-Reply-To: Date: Tue, 22 Jul 2014 09:37:56 +0200 Message-Id: <3AE875C4-0259-4741-9433-BA0A9C1DCC40@freebsd.org> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> <20140721162559.GS45513@funkthat.com> <467619B1-F530-49AF-91BF-14CA3A31908B@bsdimp.com> <20140721165619.GT45513@funkthat.com> To: Warner Losh X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Tim Kientzle , freebsd-arm , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 07:38:00 -0000 >>=20 >> The original message said why=85 >=20 > I personally think the original code should unconditionally call = load_ptr() and store_ptr() > and if the optimization for aligned access is actually worth doing, = the test for it should be > in those functions rather than inline throughout the code. The code = will be clearer, and > it would be easier to optimize those cases that actually matter. >=20 > I=92m frankly surprised that these relocations are being generated = unaligned. Perhaps that=92s > the real bug here that should be fixed. While I=92m OK with the = original patch (subject to the > above), I=92d be curious what other cases there are for this = functionality. You had said that > you had additional use cases in the network stack, but I=92m having = trouble groking the > use cases. The problem was two years ago but if I remember correctly the module = used a packed structure with function pointer inside (at least). The fix came from NetBSD: = http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-5/src/libexec/ld.elf_so/ar= ch/arm/mdreloc.c = http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-5/src/libexec/ld.elf_so/ar= ch/mips/mips_reloc.c >=20 > If this is a huge deal, then defining functions to do this is trivial. = I=92m just not sure it is common > enough to need a special macro/function call in the base. >=20 > Warner From owner-freebsd-arm@FreeBSD.ORG Tue Jul 22 21:11:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 276B485D for ; Tue, 22 Jul 2014 21:11:22 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED786271C for ; Tue, 22 Jul 2014 21:11:21 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X9hL9-000Lmv-6E; Tue, 22 Jul 2014 21:11:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6MLBEae035388; Tue, 22 Jul 2014 15:11:14 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/9LiAx+y7nlpNIh2oCdXEe X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work From: Ian Lepore To: Olavi Kumpulainen In-Reply-To: <1405809318.85788.35.camel@revolution.hippie.lan> References: <1405809318.85788.35.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 2014 15:11:13 -0600 Message-ID: <1406063473.71975.8.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:11:22 -0000 On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: > On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: > > [c++ exceptions don't work and related discussion] > > I checked in a partial fix for c++ exception handling in r268893. It > fixes the specific problem you detailed above, which was essentially > that the __gnu_Unwind_Find_exidx() function was not available in any > shared library, making the unwinder fall back to using the __exidx_start > and end symbols, which are only valid in a statically-linked app. > > With the new function in place, exceptions are closer to working with > gcc 4.2.1, but still don't work with clang. With gcc, some things work > and some things don't. For example if you throw an exception and in the > same function have a catch with the right specific type it segfaults, > but a catch(...) will catch it without problems. But you can catch an > exception by type if the catch is in a function higher up the call chain > from the place it was thrown. > > We're continuing to debug this at $work, and welcome any input if anyone > else makes progress with it. Right now we still don't know whether the > segfaults are because of bad unwinder library code or bad unwind data > emitted by gcc. (I sure hope it's the library, because that's easier to > fix.) > > On the clang front, it has been said that c++ exceptions work in clang > 3.5, so we tried the clang-devel port, and it didn't just work. But it > turns out that port hasn't been updated for quite a while, so we may not > have tested the code that's supposed to work right. While trying that I > discovered that clang 3.5 isn't scheduled for release for about another > year, so that really isn't a viable solution for anyone with near-term > needs, unless the required changes can be cherry-picked and brought into > our version of 3.4. > > -- Ian Another update to this... today I committed r268993 and r268994, and now I believe arm eabi c++ exceptions are fully working with gcc. I haven't run an extensive test suite, but all the test cases we've been using at $work to debug this now work correctly. Even with these changes, exceptions still don't work in clang 3.4 or 3.5 (this time I used a very recent 3.5 checkout). I did notice that 3.4 and 3.5 emit virtually identical unwind data, so the problem is likely to be in library code. I'm not even sure we link with the right library code in the clang case; the problem may be trying to use gcc's exception and unwind code with clang's not-quite-compatible unwind data or something like that. Also, to correct misinformation in the quoted text above, clang 3.5 is apparently scheduled for release in summer 2014 (i.e., soon), not 2015 like I originally saw on some news site. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 23 00:50:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A71357B for ; Wed, 23 Jul 2014 00:50:53 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B6402A86 for ; Wed, 23 Jul 2014 00:50:53 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id et14so582904pad.21 for ; Tue, 22 Jul 2014 17:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=v5nPFURl2nk3uBFmKJQBF4Mz3cIEOK1jYfd/PwkPKc8=; b=X6vPbdnXqYSLzLy9C1usu1XG22Pzaan7Ti31LKqSSEW4iMmhZ/b+pbPqQf0S+IZnFB MBzdvKZU2fjuLakQ1W9lZmUFszVr3l/6qdjRWqveiuEIlbMveYQdTG9GjMGevAT2MN0f wcc/uRKigxYUUrJGASeNUE3C4mzkDiqvKcEbOQwuteGpXvylTOd6NqwY03mMIAUFbzPz KKV1jAeDDzwrC+gMYqXtXRo8Rk/JZNL0/acBgIsuFodK6FQN/Q8oZ7A/EkFdPk8RMdyR t8klrllLDr/cc1W7XJ26pppwmpBNqMTxlJ1FruLHZ5UR4/1vNz9bEMThQVFk9rzCa66S HSsA== X-Received: by 10.70.102.206 with SMTP id fq14mr5994131pdb.62.1406076652487; Tue, 22 Jul 2014 17:50:52 -0700 (PDT) Received: from [172.16.1.21] (123-100-93-24.dynamic.dsl.netguardian.co.nz. [123.100.93.24]) by mx.google.com with ESMTPSA id qn7sm2372695pac.42.2014.07.22.17.50.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 17:50:51 -0700 (PDT) From: Stephen Woolerton Subject: compiling with clang33 on Pi - ld EABI issue Message-Id: <85E26AF2-3A6C-49CB-82D8-CD38682996F8@gmail.com> Date: Wed, 23 Jul 2014 12:50:46 +1200 To: FreeBSD ARM Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 00:50:53 -0000 Hi everyone, Two days later and I got llvm33 and clang33 compiled on my Raspberry Pi = - the little engine that can. I'm getting an error when I try to compile ports with clang33. And = checking the config.log file, we see... configure:3208: clang33 -O -pipe conftest.c >&5 /usr/bin/ld: ERROR: Source object /tmp/conftest-G27WNZ.o has EABI = version 0, but target a.out has EABI version 5 =20 /etc/make.conf is as follows:- CC=3Dclang33 CXX=3Dclang++33 CPP=3Dclang-cpp33 Can anyone advise how to work around the EABI issue referenced above... Thank you Stephen ----------------- Here is more information... # uname -a FreeBSD raspberry-pi 10.0-STABLE FreeBSD 10.0-STABLE #0 r268038: Tue Jul = 1 04:29:43 UTC 2014 = root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm # clang33 -v clang version 3.3 (tags/RELEASE_33/final) Target: armv6-portbld-freebsd10.0 Thread model: posix [root@raspberry-pi /usr/ports/devel/gmake]# make =3D=3D=3D> Configuring for gmake-3.82_1 =3D=3D=3D> FreeBSD 10 autotools fix applied to = /usr/ports/devel/gmake/work/make-3.82/config/config.rpath =3D=3D=3D> FreeBSD 10 autotools fix applied to = /usr/ports/devel/gmake/work/make-3.82/configure =3D=3D=3D> FreeBSD 10 autotools fix applied to = /usr/ports/devel/gmake/work/make-3.82/acinclude.m4 =3D=3D=3D> FreeBSD 10 autotools fix applied to = /usr/ports/devel/gmake/work/make-3.82/aclocal.m4 configure: loading site script /usr/ports/Templates/config.site checking for a BSD-compatible install... /usr/bin/install -c -o root -g = wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether make sets $(MAKE)... yes checking for gcc... clang33 checking whether the C compiler works... no configure: error: in `/usr/ports/devel/gmake/work/make-3.82': configure: error: C compiler cannot create executables See `config.log' for more details. =3D=3D=3D> Script "configure" failed unexpectedly. Please report the problem to autotools@FreeBSD.org [maintainer] and = attach the "/usr/ports/devel/gmake/work/make-3.82/config.log" including the = output of the failure of your make command. Also, it might be a good idea to = provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/gmake *** Error code 1 Stop. make: stopped in /usr/ports/devel/gmake ------------------------------------- # cat /usr/ports/devel/gmake/work/make-3.82/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU make configure 3.82, which was generated by GNU Autoconf 2.65. Invocation command line was $ ./configure --program-prefix=3Dg --disable-nls --prefix=3D/usr/local = --mandir=3D/usr/local/man --infodir=3D/usr/local/info/ = --build=3Darmv6-portbld-freebsd10.0 ## --------- ## ## Platform. ## ## --------- ## hostname =3D raspberry-pi uname -m =3D arm uname -r =3D 10.0-STABLE uname -s =3D FreeBSD uname -v =3D FreeBSD 10.0-STABLE #0 r268038: Tue Jul 1 04:29:43 UTC = 2014 root@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B=20 /usr/bin/uname -p =3D armv6 /bin/uname -X =3D unknown /bin/arch =3D unknown /usr/bin/arch -k =3D unknown /usr/convex/getsysinfo =3D unknown /usr/bin/hostinfo =3D unknown /bin/machine =3D unknown /usr/bin/oslevel =3D unknown /bin/universe =3D unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/games PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /root/bin ... ... ... |=20 configure:2378: checking for a BSD-compatible install configure:2446: result: /usr/bin/install -c -o root -g wheel configure:2457: checking whether build environment is sane configure:2507: result: yes configure:2648: checking for a thread-safe mkdir -p configure:2687: result: /bin/mkdir -p configure:2700: checking for gawk configure:2727: result: /usr/bin/awk configure:2738: checking whether make sets $(MAKE) configure:2760: result: yes configure:2890: checking for gcc configure:2917: result: clang33 configure:3146: checking for C compiler version configure:3155: clang33 --version >&5 clang version 3.3 (tags/RELEASE_33/final) Target: armv6-portbld-freebsd10.0 Thread model: posix configure:3166: $? =3D 0 configure:3155: clang33 -v >&5 clang version 3.3 (tags/RELEASE_33/final) Target: armv6-portbld-freebsd10.0 Thread model: posix configure:3166: $? =3D 0 configure:3155: clang33 -V >&5 clang: error: argument to '-V' is missing (expected 1 value) clang: error: no input files configure:3166: $? =3D 1 configure:3155: clang33 -qversion >&5 clang: error: no input files configure:3166: $? =3D 1 configure:3186: checking whether the C compiler works configure:3208: clang33 -O -pipe conftest.c >&5 /usr/bin/ld: ERROR: Source object /tmp/conftest-G27WNZ.o has EABI = version 0, but target a.out has EABI version 5 /usr/bin/ld: failed to merge target specific data of file = /tmp/conftest-G27WNZ.o clang: error: linker command failed with exit code 1 (use -v to see = invocation) configure:3212: $? =3D 1 configure:3250: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU make" | #define PACKAGE_TARNAME "make" | #define PACKAGE_VERSION "3.82" | #define PACKAGE_STRING "GNU make 3.82" | #define PACKAGE_BUGREPORT "bug-make@gnu.org" | #define PACKAGE_URL "http://www.gnu.org/software/make/" | #define PACKAGE "make" | #define VERSION "3.82" | /* end confdefs.h. */ |=20 | int | main () | { |=20 | ; | return 0; | } configure:3255: error: in `/usr/ports/devel/gmake/work/make-3.82': configure:3259: error: C compiler cannot create executables See `config.log' for more details. ... ... ac_cv_member_HEADER_ad=3Dyes ac_cv_member_struct___res_state_retrans=3Dyes ac_cv_member_struct_sigaction_sa_sigaction=3Dyes ac_cv_member_struct_sockaddr_in6_sin6_scope_id=3Dyes ac_cv_member_struct_stat_st_blksize=3Dyes ac_cv_path_BZIP2=3D/usr/bin/bzip2 ac_cv_path_EGREP=3D/usr/bin/egrep ac_cv_path_FGREP=3D/usr/bin/fgrep ac_cv_path_GREP=3D/usr/bin/grep ac_cv_path_GZIP=3D/usr/bin/gzip ac_cv_path_MKTEMP_COMMAND=3D/usr/bin/mktemp ac_cv_path_SED=3D/usr/bin/sed ac_cv_path_install=3D/usr/bin/install ac_cv_path_mkdir=3D/bin/mkdir ac_cv_prog_AWK=3D/usr/bin/awk ac_cv_prog_SED=3D/usr/bin/sed ac_cv_prog_ac_ct_CC=3Dclang33 ... ... ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL=3D'${SHELL} /usr/ports/devel/gmake/work/make-3.82/config/missing = --run aclocal-1.11' ALLOCA=3D'' AMDEPBACKSLASH=3D'' AMDEP_FALSE=3D'' AMDEP_TRUE=3D'' AMTAR=3D'${SHELL} /usr/ports/devel/gmake/work/make-3.82/config/missing = --run tar' AR=3D'' AUTOCONF=3D'${SHELL} = /usr/ports/devel/gmake/work/make-3.82/config/missing --run autoconf' AUTOHEADER=3D'${SHELL} = /usr/ports/devel/gmake/work/make-3.82/config/missing --run autoheader' AUTOMAKE=3D'${SHELL} = /usr/ports/devel/gmake/work/make-3.82/config/missing --run = automake-1.11' AWK=3D'/usr/bin/awk' CC=3D'clang33' CCDEPMODE=3D'' CFLAGS=3D'-O -pipe' CPP=3D'clang-cpp33' CPPFLAGS=3D'' CYGPATH_W=3D'echo' DEFS=3D'' DEPDIR=3D'' ECHO_C=3D'' ECHO_N=3D'-n' ECHO_T=3D'' EGREP=3D'' EXEEXT=3D'' GETLOADAVG_LIBS=3D'' GLOBINC=3D'' GLOBLIB=3D'' GMSGFMT=3D'' GREP=3D'' INSTALL_DATA=3D'install -o root -g wheel -m 444' INSTALL_PROGRAM=3D'install -s -o root -g wheel -m 555' INSTALL_SCRIPT=3D'install -o root -g wheel -m 555' INSTALL_STRIP_PROGRAM=3D'$(install_sh) -c -s' INTLLIBS=3D'' KMEM_GROUP=3D'' LDFLAGS=3D'' LIBICONV=3D'' LIBINTL=3D'' LIBOBJS=3D'' LIBS=3D'' LTLIBICONV=3D'' LTLIBINTL=3D'' LTLIBOBJS=3D'' MAKEINFO=3D'makeinfo --no-split' MAKE_HOST=3D'' MKDIR_P=3D'/bin/mkdir -p' MKINSTALLDIRS=3D'' MSGFMT=3D'' MSGMERGE=3D'' NEED_SETGID=3D'' OBJEXT=3D'' PACKAGE=3D'make' PACKAGE_BUGREPORT=3D'bug-make@gnu.org' PACKAGE_NAME=3D'GNU make' PACKAGE_STRING=3D'GNU make 3.82' PACKAGE_TARNAME=3D'make' PACKAGE_URL=3D'http://www.gnu.org/software/make/' PACKAGE_VERSION=3D'3.82' PATH_SEPARATOR=3D':' PERL=3D'' POSUB=3D'' RANLIB=3D'' REMOTE=3D'' SET_MAKE=3D'' SHELL=3D'/bin/sh' STRIP=3D'' USE_CUSTOMS_FALSE=3D'' USE_CUSTOMS_TRUE=3D'' USE_LOCAL_GLOB_FALSE=3D'' USE_LOCAL_GLOB_TRUE=3D'' USE_NLS=3D'' VERSION=3D'3.82' WINDOWSENV_FALSE=3D'' WINDOWSENV_TRUE=3D'' XGETTEXT=3D'' ac_ct_CC=3D'clang33' am__EXEEXT_FALSE=3D'' am__EXEEXT_TRUE=3D'' am__fastdepCC_FALSE=3D'' am__fastdepCC_TRUE=3D'' am__include=3D'' am__isrc=3D'' am__leading_dot=3D'.' am__quote=3D'' am__tar=3D'${AMTAR} chof - "$$tardir"' am__untar=3D'${AMTAR} xf -' bindir=3D'${exec_prefix}/bin' build=3D'armv6-portbld-freebsd10.0' build_alias=3D'armv6-portbld-freebsd10.0' build_cpu=3D'' build_os=3D'' build_vendor=3D'' datadir=3D'${datarootdir}' datarootdir=3D'${prefix}/share' docdir=3D'${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir=3D'${docdir}' exec_prefix=3D'NONE' host=3D'' host_alias=3D'' host_cpu=3D'' host_os=3D'' host_vendor=3D'' htmldir=3D'${docdir}' includedir=3D'${prefix}/include' infodir=3D'/usr/local/info' install_sh=3D'${SHELL} = /usr/ports/devel/gmake/work/make-3.82/config/install-sh' libdir=3D'${exec_prefix}/lib' libexecdir=3D'${exec_prefix}/libexec' localedir=3D'${datarootdir}/locale' localstatedir=3D'${prefix}/var' mandir=3D'/usr/local/man' mkdir_p=3D'/bin/mkdir -p' oldincludedir=3D'/usr/include' pdfdir=3D'${docdir}' prefix=3D'/usr/local' program_transform_name=3D's&^&g&' psdir=3D'${docdir}' sbindir=3D'${exec_prefix}/sbin' sharedstatedir=3D'${prefix}/com' sysconfdir=3D'${prefix}/etc' target_alias=3D'' ## ------------------- ## ## File substitutions. ## ## ------------------- ## MAINT_MAKEFILE=3D'' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "GNU make" #define PACKAGE_TARNAME "make" #define PACKAGE_VERSION "3.82" #define PACKAGE_STRING "GNU make 3.82" #define PACKAGE_BUGREPORT "bug-make@gnu.org" #define PACKAGE_URL "http://www.gnu.org/software/make/" #define PACKAGE "make" #define VERSION "3.82" configure: exit 77= From owner-freebsd-arm@FreeBSD.ORG Wed Jul 23 16:27:58 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A63A258D; Wed, 23 Jul 2014 16:27:58 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65D342F3D; Wed, 23 Jul 2014 16:27:57 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s6NGQqL1023777; Wed, 23 Jul 2014 11:27:50 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1na225g8q1-1; Wed, 23 Jul 2014 11:27:49 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 6BC1F460110; Wed, 23 Jul 2014 11:27:49 -0500 (CDT) Message-ID: <53CFE285.9040101@rice.edu> Date: Wed, 23 Jul 2014 11:27:49 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "arm@freebsd.org" Subject: testing new pmap code X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------020007010401020701030001" X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.713890987064109 urlsuspect_oldscore=0.713890987064109 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.713890987064109 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407230199 Cc: Konstantin Belousov , Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:27:58 -0000 This is a multi-part message in MIME format. --------------020007010401020701030001 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, About a week ago I committed some new pmap code on all architectures, including arm. However, that code isn't "active" until the attached patch is committed. Before I commit this patch, I'd like to ask people to test it on arm "classic" and especially v6. (The v6 pmap changes were more complicated.) Here is how to test it. Before you apply the kernel patch, compile and run the attached program, mlockall2A.c, in a loop. Something like this: # while ( 1 ) while? ./mlockall2A while? sysctl vm.stats.vm.v_wire_count while? sleep 7 while? end You should see the wire count steadily increase, because there is a wired page leak. Now, apply the kernel patch, and repeat the same test. This time, the wire count should stabilize. If you're testing on arm v6, substitute sysctl vm.stats.vm.v_wire_count vm.pmap.section for sysctl vm.stats.vm.v_wire_count so that I can verify that we're handling superpages correctly. Thanks, Alan --------------020007010401020701030001 Content-Type: text/plain; charset=ISO-8859-15; name="vm_map_entry_unwire7.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vm_map_entry_unwire7.patch" Index: vm/vm_extern.h =================================================================== --- vm/vm_extern.h (revision 268597) +++ vm/vm_extern.h (working copy) @@ -81,7 +81,6 @@ int vm_fault_hold(vm_map_t map, vm_offset_t vaddr, int fault_flags, vm_page_t *m_hold); int vm_fault_quick_hold_pages(vm_map_t map, vm_offset_t addr, vm_size_t len, vm_prot_t prot, vm_page_t *ma, int max_count); -void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); int vm_forkproc(struct thread *, struct proc *, struct thread *, struct vmspace *, int); void vm_waitproc(struct proc *); Index: vm/vm_fault.c =================================================================== --- vm/vm_fault.c (revision 268597) +++ vm/vm_fault.c (working copy) @@ -106,6 +106,7 @@ __FBSDID("$FreeBSD$"); #define PFFOR 4 static int vm_fault_additional_pages(vm_page_t, int, int, vm_page_t *, int *); +static void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); #define VM_FAULT_READ_BEHIND 8 #define VM_FAULT_READ_MAX (1 + VM_FAULT_READ_AHEAD_MAX) @@ -1186,7 +1187,7 @@ vm_fault_wire(vm_map_t map, vm_offset_t start, vm_ * * Unwire a range of virtual addresses in a map. */ -void +static void vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_offset_t end, boolean_t fictitious) { Index: vm/vm_map.c =================================================================== --- vm/vm_map.c (revision 268597) +++ vm/vm_map.c (working copy) @@ -132,6 +132,7 @@ static void _vm_map_init(vm_map_t map, pmap_t pmap vm_offset_t max); static void vm_map_entry_deallocate(vm_map_entry_t entry, boolean_t system_map); static void vm_map_entry_dispose(vm_map_t map, vm_map_entry_t entry); +static void vm_map_entry_unwire(vm_map_t map, vm_map_entry_t entry); #ifdef INVARIANTS static void vm_map_zdtor(void *mem, int size, void *arg); static void vmspace_zdtor(void *mem, int size, void *arg); @@ -2393,16 +2394,10 @@ done: (entry->eflags & MAP_ENTRY_USER_WIRED))) { if (user_unwire) entry->eflags &= ~MAP_ENTRY_USER_WIRED; - entry->wired_count--; - if (entry->wired_count == 0) { - /* - * Retain the map lock. - */ - vm_fault_unwire(map, entry->start, entry->end, - entry->object.vm_object != NULL && - (entry->object.vm_object->flags & - OBJ_FICTITIOUS) != 0); - } + if (entry->wired_count == 1) + vm_map_entry_unwire(map, entry); + else + entry->wired_count--; } KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) != 0, ("vm_map_unwire: in-transition flag missing %p", entry)); @@ -2635,19 +2630,12 @@ done: * unnecessary. */ entry->wired_count = 0; - } else { - if (!user_wire || - (entry->eflags & MAP_ENTRY_USER_WIRED) == 0) + } else if (!user_wire || + (entry->eflags & MAP_ENTRY_USER_WIRED) == 0) { + if (entry->wired_count == 1) + vm_map_entry_unwire(map, entry); + else entry->wired_count--; - if (entry->wired_count == 0) { - /* - * Retain the map lock. - */ - vm_fault_unwire(map, entry->start, entry->end, - entry->object.vm_object != NULL && - (entry->object.vm_object->flags & - OBJ_FICTITIOUS) != 0); - } } next_entry_done: KASSERT((entry->eflags & MAP_ENTRY_IN_TRANSITION) != 0, @@ -2783,9 +2771,11 @@ vm_map_sync( static void vm_map_entry_unwire(vm_map_t map, vm_map_entry_t entry) { - vm_fault_unwire(map, entry->start, entry->end, - entry->object.vm_object != NULL && - (entry->object.vm_object->flags & OBJ_FICTITIOUS) != 0); + + VM_MAP_ASSERT_LOCKED(map); + pmap_unwire(map->pmap, entry->start, entry->end); + vm_object_unwire(entry->object.vm_object, entry->offset, entry->end - + entry->start, PQ_ACTIVE); entry->wired_count = 0; } Index: vm/vm_object.c =================================================================== --- vm/vm_object.c (revision 268597) +++ vm/vm_object.c (working copy) @@ -2200,6 +2200,78 @@ vm_object_set_writeable_dirty(vm_object_t object) vm_object_set_flag(object, OBJ_MIGHTBEDIRTY); } +/* + * vm_object_unwire: + * + * For each page offset within the specified range of the given object, + * find the highest-level page in the shadow chain and unwire it. A page + * must exist at every page offset, and the highest-level page must be + * wired. + */ +void +vm_object_unwire(vm_object_t object, vm_ooffset_t offset, vm_size_t length, + uint8_t queue) +{ + vm_object_t tobject; + vm_page_t m, tm; + vm_pindex_t end_pindex, pindex, tpindex; + int depth, locked_depth; + + KASSERT((offset & PAGE_MASK) == 0, + ("vm_object_unwire: offset is not page aligned")); + KASSERT((length & PAGE_MASK) == 0, + ("vm_object_unwire: length is not a multiple of PAGE_SIZE")); + /* The wired count of a fictitious page never changes. */ + if ((object->flags & OBJ_FICTITIOUS) != 0) + return; + pindex = OFF_TO_IDX(offset); + end_pindex = pindex + atop(length); + locked_depth = 1; + VM_OBJECT_RLOCK(object); + m = vm_page_find_least(object, pindex); + while (pindex < end_pindex) { + if (m == NULL || pindex < m->pindex) { + /* + * The first object in the shadow chain doesn't + * contain a page at the current index. Therefore, + * the page must exist in a backing object. + */ + tobject = object; + tpindex = pindex; + depth = 0; + do { + tpindex += + OFF_TO_IDX(tobject->backing_object_offset); + tobject = tobject->backing_object; + KASSERT(tobject != NULL, + ("vm_object_unwire: missing page")); + if ((tobject->flags & OBJ_FICTITIOUS) != 0) + goto next_page; + depth++; + if (depth == locked_depth) { + locked_depth++; + VM_OBJECT_RLOCK(tobject); + } + } while ((tm = vm_page_lookup(tobject, tpindex)) == + NULL); + } else { + tm = m; + m = TAILQ_NEXT(m, listq); + } + vm_page_lock(tm); + vm_page_unwire(tm, queue); + vm_page_unlock(tm); +next_page: + pindex++; + } + /* Release the accumulated object locks. */ + for (depth = 0; depth < locked_depth; depth++) { + tobject = object->backing_object; + VM_OBJECT_RUNLOCK(object); + object = tobject; + } +} + #include "opt_ddb.h" #ifdef DDB #include Index: vm/vm_object.h =================================================================== --- vm/vm_object.h (revision 268597) +++ vm/vm_object.h (working copy) @@ -290,6 +290,8 @@ void vm_object_shadow (vm_object_t *, vm_ooffset_t void vm_object_split(vm_map_entry_t); boolean_t vm_object_sync(vm_object_t, vm_ooffset_t, vm_size_t, boolean_t, boolean_t); +void vm_object_unwire(vm_object_t object, vm_ooffset_t offset, + vm_size_t length, uint8_t queue); #endif /* _KERNEL */ #endif /* _VM_OBJECT_ */ --------------020007010401020701030001 Content-Type: text/plain; charset=ISO-8859-15; name="mlockall2A.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mlockall2A.c" #include #include #include int main(void) { size_t pagesize[2]; void *p; int flags = MAP_ANON | MAP_PRIVATE, sizes; if ((sizes = getpagesizes(pagesize, 2)) == -1) err(1, "getpagesizes"); if (sizes < 2) { pagesize[1] = 4 * 1024 * 1024; warnx("Faking pagesize[1] as %zu", pagesize[1]); } if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1) err(1, "mlock"); if ((p = mmap(NULL, 3 * pagesize[1], PROT_READ | PROT_WRITE, flags, -1, 0)) == MAP_FAILED) err(1, "mmap"); if (mprotect(p, pagesize[1] + pagesize[0], PROT_NONE) == -1) err(1, "mprotect"); return (0); } --------------020007010401020701030001-- From owner-freebsd-arm@FreeBSD.ORG Wed Jul 23 18:47:26 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 309EE44D; Wed, 23 Jul 2014 18:47:26 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F30542D1D; Wed, 23 Jul 2014 18:47:25 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6NIlIxw082031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2014 11:47:19 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6NIlIUL082030; Wed, 23 Jul 2014 11:47:18 -0700 (PDT) (envelope-from jmg) Date: Wed, 23 Jul 2014 11:47:18 -0700 From: John-Mark Gurney To: Alan Cox Subject: Re: testing new pmap code Message-ID: <20140723184718.GL43962@funkthat.com> Mail-Followup-To: Alan Cox , "arm@freebsd.org" , Konstantin Belousov References: <53CFE285.9040101@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CFE285.9040101@rice.edu> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 23 Jul 2014 11:47:19 -0700 (PDT) Cc: "arm@freebsd.org" , Konstantin Belousov X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:47:26 -0000 Alan Cox wrote this message on Wed, Jul 23, 2014 at 11:27 -0500: > About a week ago I committed some new pmap code on all architectures, > including arm. However, that code isn't "active" until the attached > patch is committed. Before I commit this patch, I'd like to ask people > to test it on arm "classic" and especially v6. (The v6 pmap changes > were more complicated.) Tested on AVILA... W/o the kernel patch the machine froze after only a few loops... I will admit that the kernel that froze was old code from a couple months ago... w/ the patch (and a current HEAD), it's stable and has looped many more times than the previous kernel... Tested w/ the patch: FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #30 r269019M: Wed Jul 23 11:17:28 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Jul 23 20:36:57 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78F3B81F; Wed, 23 Jul 2014 20:36:57 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D81C27DB; Wed, 23 Jul 2014 20:36:56 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s6NKRrG6010834; Wed, 23 Jul 2014 15:36:54 -0500 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by pp1.rice.edu with ESMTP id 1n9btt0wsf-1; Wed, 23 Jul 2014 15:36:54 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from [10.87.78.95] (unknown [10.87.78.95]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 6F43A500108; Wed, 23 Jul 2014 15:36:54 -0500 (CDT) Subject: Re: testing new pmap code Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alan Cox In-Reply-To: <20140723184718.GL43962@funkthat.com> Date: Wed, 23 Jul 2014 15:37:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98535E80-EDB6-4EAE-9570-567737904A3C@rice.edu> References: <53CFE285.9040101@rice.edu> <20140723184718.GL43962@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.248919945447816 urlsuspect_oldscore=0.248919945447816 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.248919945447816 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407230245 Cc: "arm@freebsd.org" , Konstantin Belousov X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:36:57 -0000 On Jul 23, 2014, at 1:47 PM, John-Mark Gurney wrote: > Alan Cox wrote this message on Wed, Jul 23, 2014 at 11:27 -0500: >> About a week ago I committed some new pmap code on all architectures, >> including arm. However, that code isn't "active" until the attached >> patch is committed. Before I commit this patch, I'd like to ask = people >> to test it on arm "classic" and especially v6. (The v6 pmap changes >> were more complicated.) >=20 > Tested on AVILA... W/o the kernel patch the machine froze after only > a few loops... I will admit that the kernel that froze was old code > from a couple months ago... >=20 > w/ the patch (and a current HEAD), it's stable and has looped many = more > times than the previous kernel... >=20 > Tested w/ the patch: > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #30 = r269019M: Wed Jul 23 11:17:28 PDT 2014 = jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA arm >=20 Thank you for the quick response. Alan From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 09:58:59 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82CF3CC5 for ; Fri, 25 Jul 2014 09:58:59 +0000 (UTC) Received: from eu1sys200aog113.obsmtp.com (eu1sys200aog113.obsmtp.com [207.126.144.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5DE92C1E for ; Fri, 25 Jul 2014 09:58:57 +0000 (UTC) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by eu1sys200aob113.postini.com ([207.126.147.11]) with SMTP ID DSNKU9IqWraRCr4VdqobZyCmx+Is7HfLwdYB@postini.com; Fri, 25 Jul 2014 09:58:58 UTC Received: by mail-wi0-f182.google.com with SMTP id d1so677694wiv.15 for ; Fri, 25 Jul 2014 02:58:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=cuzi5eSqOGhWpI8BQfO1RTwigqgr+dVsZ9NSMLC9jZM=; b=lDn+LP8kwJILyPFTatZFPFrSr/be4r50yHp7w3P74NXTBiLrW8TowTdhCKRmQjDFlm qrp+VSyduraXBwYx78yo8zPVg96C1J9qmrgtrs2IA3QC4pX8ctwJtpVN7R8Oe7uvlJrl +sQT2mIxdedzjLgQCuDdL7cz4BT1fPzaZl0gA0zhpCokv6nUdGqHmu1aVZK3khoOu4P8 6e5iclyLmXqxYoAcxCPWjHvAVIeMNe4luYjRiy3o1Xkz925Jrc5PiDNiqImLT3Th9Eup z+A0VZOX388ZlvkpxgkWGtLtamXZNqjyOlJO3N5rpd2VpahUBPjrreWWb5vBMObV47Jk cUTQ== X-Received: by 10.194.103.38 with SMTP id ft6mr19660709wjb.18.1406280691880; Fri, 25 Jul 2014 02:31:31 -0700 (PDT) X-Gm-Message-State: ALoCoQnpX0qR4VUUz5qBZUPlvX29w2vEdKnCACf15YEfRc9Bpid5pUMclge6Oc7aINSzNxvL6ceGJrtyfWMM+31AYF+/Q0HNOtJLe4XuThZpaFaUG3U9YHdKuWfxkCYvjbPlVsET1ReE X-Received: by 10.194.103.38 with SMTP id ft6mr19660572wjb.18.1406280690677; Fri, 25 Jul 2014 02:31:30 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id de6sm23700635wjc.16.2014.07.25.02.31.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 02:31:29 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6P9VRc3003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Jul 2014 10:31:28 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6P9VRUW003914 for freebsd-arm@freebsd.org; Fri, 25 Jul 2014 10:31:27 +0100 (BST) (envelope-from mexas) Date: Fri, 25 Jul 2014 10:31:27 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407250931.s6P9VRUW003914@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: RPi-B buildworld times Reply-To: mexas@bristol.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:58:59 -0000 Not too bad: -------------------------------------------------------------- >>> World build completed on Tue Jul 22 05:13:40 UTC 2014 -------------------------------------------------------------- 20h38m1.24s real 14h23m1.10s user 5h39m33.56s sys 137532 maximum resident set size 453 average shared memory size 430 average unshared data size 127 average unshared stack size 69240972 page reclaims 10861 page faults 1806 swaps 54536 block input operations 4511 block output operations 0 messages sent 0 messages received 0 signals received 1266548 voluntary context switches 13248916 involuntary context switches This is with: # cat /etc/make.conf # for armv6 WITH_GCC=yes WITH_GNUCXX=yes WITH_GCC_BOOTSTRAP=yes WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes WITHOUT_CLANG_BOOTSTRAP=yes # end for armv6 Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 14:11:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FC3E6CD for ; Fri, 25 Jul 2014 14:11:02 +0000 (UTC) Received: from eu1sys200aog128.obsmtp.com (eu1sys200aog128.obsmtp.com [207.126.144.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6292A257D for ; Fri, 25 Jul 2014 14:11:00 +0000 (UTC) Received: from mail-we0-f174.google.com ([74.125.82.174]) (using TLSv1) by eu1sys200aob128.postini.com ([207.126.147.11]) with SMTP ID DSNKU9JlVteQOc4yrwAEbkIctTTlzfrKoamd@postini.com; Fri, 25 Jul 2014 14:11:01 UTC Received: by mail-we0-f174.google.com with SMTP id x48so4287129wes.19 for ; Fri, 25 Jul 2014 07:10:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:reply-to; bh=4Xe22FV0VTfJOm42opzEu+n8h7LvbTt7CxB7o42lGwI=; b=U+Q2d42sG3gjIXNy9s/1GET2dXeHFJLFLK4coknZ9ovKwwmqY+NfFSuYOeJGM5HPWA oLaM7qivAazUV2ev+CUfsT/PZxeOu6sNkTWs1n5q+9Mnh3sBRKPTjy1h6cwxp6H02pPR YjeNHvqOmXBJmDXm5GNSx55CAooNcZrVVrJ6z0JR+krzBUcncoXiL90oZF5JVOPPJkA3 aBBZwp3kPiVK2DoBE9od6y2TR8seBqzrjKhU85pr0EtFhWeY9LBAOfhlCnJG9dqpvlAM ri82Pb5y7K+Pu668fjtXhVR9qpXNs6EfTLtjiRRVsmpAFGOWMDjSzMhL8mN7Q7aiW1Xd skPQ== X-Gm-Message-State: ALoCoQnpAUOS7tZONbXXJJlUdhnznLvJvSStLL/M4wEscMYQhXze1bIvaE013BpJl8ILNOYyFpJL7kOkSjIbSihzmozYMKNaoQgPz1acVu2/P8nWDg2HSv6JRc0O4NvGR+6LdjZnQFT1 X-Received: by 10.194.78.4 with SMTP id x4mr6270009wjw.44.1406297430072; Fri, 25 Jul 2014 07:10:30 -0700 (PDT) X-Received: by 10.194.78.4 with SMTP id x4mr6269966wjw.44.1406297429694; Fri, 25 Jul 2014 07:10:29 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPSA id u10sm6390517wix.14.2014.07.25.07.10.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 07:10:29 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8) with ESMTP id s6PEAQmL005419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 25 Jul 2014 15:10:26 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.8/8.14.8/Submit) id s6PEAQxQ005418 for freebsd-arm@freebsd.org; Fri, 25 Jul 2014 15:10:26 +0100 (BST) (envelope-from mexas) Date: Fri, 25 Jul 2014 15:10:26 +0100 (BST) From: Anton Shterenlikht Message-Id: <201407251410.s6PEAQxQ005418@mech-cluster241.men.bris.ac.uk> To: freebsd-arm@freebsd.org Subject: kldxref: Skipping /boot/kernel/kernel.gz.tramp: not dynamically-linked Reply-To: mexas@bristol.ac.uk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 14:11:02 -0000 On make installkernel I see this warning(?) ===> zlib (install) install -o root -g wheel -m 555 zlib.ko /boot/kernel install -o root -g wheel -m 555 zlib.ko.symbols /boot/kernel kldxref /boot/kernel kldxref: Skipping /boot/kernel/kernel.gz.tramp: not dynamically-linked # Can I safely ignore it? Thanks Anton From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 16:15:31 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57E70E0F for ; Fri, 25 Jul 2014 16:15:31 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12B522263 for ; Fri, 25 Jul 2014 16:15:30 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id c1so1026249igq.13 for ; Fri, 25 Jul 2014 09:15:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=i5wg3S1inBd4bsyhyvlxH9/tO9Iw4l/Jghc3JDHAAvQ=; b=MJ0QhrEAQJHfuOQYwGhiB1Gei0/J6MKLj6jWPGqs6GccRDkuVPW2Xu8+olnIlNqBBc OZriEsVpcdcepvyIW+OlTI+pGIkoQvk5CU+3/J6AIobc3eEZ3ZcNKYL9uiIsSDpNha1o U1c69XqwS88BrUntpIMyUXjbyh0azrulv68+5jSbN/DBIu00QCRW7SpApI2Y8ALuYN+r tZnKZKgAnflTownkBy6lqIqOt/iqdMoicWYjGnmPMfEZd5bZY/N/IwTBZugozjXA1Tz4 yJBIUhmYYYiRmuxgAV4LDE0P7QDKFYQ90GESDJIJT6YvOXpfOlRjszS2ZTvHBuHMtpkL VbtA== X-Gm-Message-State: ALoCoQlApzaTBNd9HxiV2jUrv+Nybt58n99ULXxo/IW/CwV0rcaTclRp7/4Y7htNL/imCvGLiipv X-Received: by 10.51.17.2 with SMTP id ga2mr7132061igd.12.1406304923922; Fri, 25 Jul 2014 09:15:23 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id n1sm5802153igp.1.2014.07.25.09.15.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 09:15:23 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5B9809BA-BBB7-4B79-979B-2B8D114F3361"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RPi-B buildworld times From: Warner Losh In-Reply-To: <201407250931.s6P9VRUW003914@mech-cluster241.men.bris.ac.uk> Date: Fri, 25 Jul 2014 10:15:21 -0600 Message-Id: References: <201407250931.s6P9VRUW003914@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:15:31 -0000 --Apple-Mail=_5B9809BA-BBB7-4B79-979B-2B8D114F3361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 25, 2014, at 3:31 AM, Anton Shterenlikht = wrote: > Not too bad: >=20 > -------------------------------------------------------------- >>>> World build completed on Tue Jul 22 05:13:40 UTC 2014 > -------------------------------------------------------------- > 20h38m1.24s real 14h23m1.10s user = 5h39m33.56s sys > 137532 maximum resident set size > 453 average shared memory size > 430 average unshared data size > 127 average unshared stack size > 69240972 page reclaims > 10861 page faults > 1806 swaps > 54536 block input operations > 4511 block output operations > 0 messages sent > 0 messages received > 0 signals received > 1266548 voluntary context switches > 13248916 involuntary context switches >=20 > This is with: >=20 > # cat /etc/make.conf=20 > # for armv6 > WITH_GCC=3Dyes > WITH_GNUCXX=3Dyes > WITH_GCC_BOOTSTRAP=3Dyes > WITHOUT_CLANG=3Dyes > WITHOUT_CLANG_IS_CC=3Dyes > WITHOUT_CLANG_BOOTSTRAP=3Dyes > # end for armv6 Cool (sorry about the hassle on the compiler specification, new goodness = coming on that front) 20 hours! Wow! My 486DX33 with 32MB RAM was able to buildworld (granted = FreeBSD 1.1) in about 16 or 17 hours (8 or 9 if I disabled a boatload of = junk I never used). Of course, that same box would almost not be able to run FreeBSD today, = let alone do a buildworld with the big-bloated pig dogs of gcc and = clang=85 :) Warner --Apple-Mail=_5B9809BA-BBB7-4B79-979B-2B8D114F3361 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT0oKZAAoJEGwc0Sh9sBEABCUP/3PLathEPJNU8DPVM/zm3Tex wwqhpmcLVzj+cA2QqM/zQ7CGLR/de/2G3WRFsDDDRciEltfUxhR+5QVTt9Rt0RkF BTkj4uBoLbpHXY+SozDp6ppwzQETNTQV55yN0Drmj/mQdQis7SuFBLpW0Vt5HRQ9 tUL8TGnAf8zZYX0maskNROyMhMz6zYXar/VsXvt7vkmIOIJILeDIaGdeJtF+lVJ7 vWc750ezMlYrJICPlOCp0vtt4KthhcMPFHn260RByTR4x3RKC9Qs8gkBMIJJhZWm 7qlL127xMWdqQ9hnf+LbVwxYbhZWCfYbO0rjqbm5e4a4mN1PZ2KLQDF1O/exeypi dKflhoZrkyUL8jgbwsqCHD++++gdX4FNZdw9eey+jpLIufSpJSP165Cx8gysfYeR WjXQPBOoXvxjhLx7X+yF4IMR1qFlpwbebgfxywlvgYgb+4k/UY8sI3za5PJJ6nBb pFG5uIcBI8znLXLefZyIC9U2IT0szhV0RdHfOHFXg4O15wdqUDD+RrW+ekaWB3hQ 0om28GyOH4JfeF4GPQR4ZI/OYpc/U8+89Pyqsl0RBRh9JnkEF32ujTpEMeopGhKw AXAxX06di1o8x9Rfpv9DiP3cxgipSSDolCgvT1u5rkRUA8LbyJJvXL5cAfmWpqMb tRN497fEG62DiAAO3DCZ =dUFH -----END PGP SIGNATURE----- --Apple-Mail=_5B9809BA-BBB7-4B79-979B-2B8D114F3361-- From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 16:18:06 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92CD9F83 for ; Fri, 25 Jul 2014 16:18:06 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46903228C for ; Fri, 25 Jul 2014 16:18:05 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id rl12so3995527iec.1 for ; Fri, 25 Jul 2014 09:17:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=m21TB0NocdR9Gw7718ve7T9cYyFUqW6/seOb0hMhRRE=; b=Y+QCip7DHEX0ypkIsEzirs1bTaDxrqiiED5LVoVvr6IIpra2yFa7ct8I5c+05zEOZ9 3WF6vVKNQPbmrN1am2Jj4Un/VKMmqQ5e3Od4HPI90iYCXZyzQXaXoafeCKPXGIhbqI17 IPqneISsbujm7f0FhRI5RxXxn/QHkI8A3KdXZTqhy2waZqWU/UiXtYEzGBxqNVeXwk7p NhUnzNg52ZXa5soTJISAyRA484GLcnjPR3NsdRelhs78ZTXn/5/fAVYNhflTV4KNEAk9 EV3JdS2sN/ed0ykbhD90MORnCbe0U7p9ChGvywl2jb9Pq8AFAR39FtFxGj5yEImwsuyS Z02A== X-Gm-Message-State: ALoCoQlCNIQJx0zmrnrUpOUgXrgVCFOhY3mCBfBx+eSjIwvxTmADhMGgRdB6QZo6PF/xDVTnoptJ X-Received: by 10.42.67.203 with SMTP id u11mr22545981ici.20.1406305079622; Fri, 25 Jul 2014 09:17:59 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ik1sm5770064igb.18.2014.07.25.09.17.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 09:17:53 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_1FBE8079-236F-4070-83C1-2C5AB9BE4C18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: kldxref: Skipping /boot/kernel/kernel.gz.tramp: not dynamically-linked From: Warner Losh In-Reply-To: <201407251410.s6PEAQxQ005418@mech-cluster241.men.bris.ac.uk> Date: Fri, 25 Jul 2014 10:17:52 -0600 Message-Id: <1EF074C5-9FC7-4D3A-B235-7D8087E230D3@bsdimp.com> References: <201407251410.s6PEAQxQ005418@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:18:06 -0000 --Apple-Mail=_1FBE8079-236F-4070-83C1-2C5AB9BE4C18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 25, 2014, at 8:10 AM, Anton Shterenlikht = wrote: > On make installkernel I see this warning(?) >=20 > =3D=3D=3D> zlib (install) > install -o root -g wheel -m 555 zlib.ko /boot/kernel > install -o root -g wheel -m 555 zlib.ko.symbols /boot/kernel > kldxref /boot/kernel > kldxref: Skipping /boot/kernel/kernel.gz.tramp: not dynamically-linked > #=20 >=20 > Can I safely ignore it? Yes. kldxref only matters for modules, and that=92s the kernel. Warner --Apple-Mail=_1FBE8079-236F-4070-83C1-2C5AB9BE4C18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT0oMwAAoJEGwc0Sh9sBEA3BIP/2WeRnqvTLdPNWhTvdZRCJhf X0TBr1tnVL6TJYtIPOQ8ugKwTgyH8lJsWjlnoscLeKPul77NFEuKBMyWtX1O0Pc7 IuAF0raJEMGNOp69dy4KyJzpT1hkQmCxfCL6DD4lsf3gNNUkhU2O0GdfFL+UtGW0 3GNCPIfXeaPj/PljS0wLE1z9CpN3J9rcSBMvSH/QNEILkYZ7GRGEd45HGDMg9sqT J97ONeACNG2ikKyf7/6czABG1VeYsqghJ4JMzsGYofNHdgUmXv/kicDAvuTmbYhJ iQuhoGKEILgFrmvaAAja2VD91DQq4O3p5BTsGOis+ss8kKXcLLFyXetWzaW7coLY LkOqGAA4UhzmVxssTIi53Q1V6gEwiRUjya0PiWm2seEhLI2ktO5pWOQi+q8F4hWU Z01PEP3pJYorrrLkBosiyW9/cHp606Kicg9lp1JfqAZrMG+6m1uG/5L5fryQrCM2 Jnd4NtlcBf9vJwIvTBnAJ3lQZzX8EhpQqmBtJbD9qT0cJFbHwGQhHFxhV5gq+Rb6 knVOClJxjPeyVCGtak9vJRKzoQU5KO2HAvxJ6mb20iVAiyWJN3DeMTPVM8t6seVa i3T44JM8b0dmeoGfeHUbu9sdI29IiewetMVeNcGAYMGEBWWvjPhhDwfAzr06WGeV 4LbnQQ+wm19pQHm2/n+l =Hu3N -----END PGP SIGNATURE----- --Apple-Mail=_1FBE8079-236F-4070-83C1-2C5AB9BE4C18-- From owner-freebsd-arm@FreeBSD.ORG Fri Jul 25 21:44:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A096163; Fri, 25 Jul 2014 21:44:39 +0000 (UTC) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A386D2102; Fri, 25 Jul 2014 21:44:37 +0000 (UTC) Received: from [192.168.225.11] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id s6PLiUNA054804; Fri, 25 Jul 2014 23:44:34 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <53D2CFBE.3040207@fgznet.ch> Date: Fri, 25 Jul 2014 23:44:30 +0200 From: Andreas Tobler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: C++ exceptions in freebsd-arm doesn't seem to work References: <1405809318.85788.35.camel@revolution.hippie.lan> <1406063473.71975.8.camel@revolution.hippie.lan> In-Reply-To: <1406063473.71975.8.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:44:39 -0000 On 22.07.14 23:11, Ian Lepore wrote: > On Sat, 2014-07-19 at 16:35 -0600, Ian Lepore wrote: >> On Sat, 2014-06-07 at 14:12 +0200, Olavi Kumpulainen wrote: >>> [c++ exceptions don't work and related discussion] >> >> I checked in a partial fix for c++ exception handling in r268893. It >> fixes the specific problem you detailed above, which was essentially >> that the __gnu_Unwind_Find_exidx() function was not available in any >> shared library, making the unwinder fall back to using the __exidx_start >> and end symbols, which are only valid in a statically-linked app. >> >> With the new function in place, exceptions are closer to working with >> gcc 4.2.1, but still don't work with clang. With gcc, some things work >> and some things don't. For example if you throw an exception and in the >> same function have a catch with the right specific type it segfaults, >> but a catch(...) will catch it without problems. But you can catch an >> exception by type if the catch is in a function higher up the call chain >> from the place it was thrown. >> >> We're continuing to debug this at $work, and welcome any input if anyone >> else makes progress with it. Right now we still don't know whether the >> segfaults are because of bad unwinder library code or bad unwind data >> emitted by gcc. (I sure hope it's the library, because that's easier to >> fix.) >> >> On the clang front, it has been said that c++ exceptions work in clang >> 3.5, so we tried the clang-devel port, and it didn't just work. But it >> turns out that port hasn't been updated for quite a while, so we may not >> have tested the code that's supposed to work right. While trying that I >> discovered that clang 3.5 isn't scheduled for release for about another >> year, so that really isn't a viable solution for anyone with near-term >> needs, unless the required changes can be cherry-picked and brought into >> our version of 3.4. >> >> -- Ian > > Another update to this... today I committed r268993 and r268994, and now > I believe arm eabi c++ exceptions are fully working with gcc. I haven't > run an extensive test suite, but all the test cases we've been using at > $work to debug this now work correctly. Thank you! Confirmed. My test cases which are working with gcc-4.10 are now also working with the system gcc, 4.2.1. I totally forgot about this change. I have it in my local gcc tree since a while but I forgot about..... Andreas From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:16:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75EEEAB9 for ; Sat, 26 Jul 2014 04:16:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4358920B8 for ; Sat, 26 Jul 2014 04:16:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6Q4Gn71082964 for ; Sat, 26 Jul 2014 04:16:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 155894] [at91] [patch] Enable at91 booting from SDHC (high capacity) cards Date: Sat, 26 Jul 2014 04:16:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:16:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155894 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Sat Jul 26 04:16:05 UTC 2014 New revision: 269113 URL: http://svnweb.freebsd.org/changeset/base/269113 Log: Enable at91 systems to boot from high capacity SD cards. This also fixes a few minor violations of the SD protocol, such as running the bus at high speed during the card identification sequence. The sdcard_init() routine now probes for SDHC cards so that later read requests can make needed adjustments between block and byte offsets based on card type. There is a new MCI_readblocks() function that takes block number and block count parameters instead of byte-offset values. Using this routine, boot loader code can load a kernel from any location on an SDHC or standard SD. The old MCI_read() interface remains unchanged so that existing customized boot loader code will still keep working without changes. Using this routine, boot loaders can load a kernel from anywhere in the first 4GB of an SDHC card (or of course any location on a standard SD card). A new sdcard_use4wire() routine allows boot loaders to request 4-bit transfers; it should be called after sdcard_init(). The sdcard_init() routine no longer assumes the hardware is 4-wire capable and by default sets things up for 1-bit transfers. (4-wire mode is unreliable on at91rm9200, works on later SoCs.) PR: 155894 Submitted by: me. years ago. Changes: head/sys/boot/arm/at91/libat91/mci_device.h head/sys/boot/arm/at91/libat91/sd-card.c head/sys/boot/arm/at91/libat91/sd-card.h -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:18:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0135BC1 for ; Sat, 26 Jul 2014 04:18:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A785C20CC for ; Sat, 26 Jul 2014 04:18:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6Q4I2gV097096 for ; Sat, 26 Jul 2014 04:18:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 155894] [at91] [patch] Enable at91 booting from SDHC (high capacity) cards Date: Sat, 26 Jul 2014 04:18:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:18:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155894 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ian@FreeBSD.org Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:21:16 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF1F8C46 for ; Sat, 26 Jul 2014 04:21:16 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D75D5215E for ; Sat, 26 Jul 2014 04:21:16 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6Q4LGvv038746 for ; Sat, 26 Jul 2014 04:21:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 161110] /usr/src/sys/arm/include/signal.h is bad Date: Sat, 26 Jul 2014 04:21:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:21:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161110 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ian@FreeBSD.org Resolution|--- |FIXED --- Comment #1 from Ian Lepore --- Fix was committed in r248153 on 2013-03-11 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:26:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0811DA6 for ; Sat, 26 Jul 2014 04:26:08 +0000 (UTC) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 69396219F for ; Sat, 26 Jul 2014 04:26:07 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mailssl.asahi-net.or.jp (Postfix) with ESMTP id 90CCF10A39 for ; Sat, 26 Jul 2014 13:09:15 +0900 (JST) Date: Sat, 26 Jul 2014 13:09:09 +0900 (JST) Message-Id: <20140726.130909.1154868204943313876.shigeru@os-hackers.jp> To: freebsd-arm@freebsd.org Subject: dmesg on RaspberryPi Type B+ From: YAMAMOTO Shigeru X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sat_Jul_26_13_09_09_2014_456)--" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:26:08 -0000 ----Next_Part(Sat_Jul_26_13_09_09_2014_456)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all, I get a New RaspberryPi, RaspberryPi Type B+. I make new SD image and I test it on RaspberryPi Type B+. There is no problem. My SD images is at http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20140725/raspberry-pi/ Next, I test newest SD image at http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-arm-armv6-RPI-B-20140701-r268111.img.bz2. It can't detect USB Ethernet device. It seems me to need change firmware to newer at, https://github.com/raspberrypi/firmware Thanks, --- YAMAMOTO Shigeru ----Next_Part(Sat_Jul_26_13_09_09_2014_456)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="raspberrypib+.dmesg.txt" KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r269079M: Fri Jul 25 13:39:57 JST 2014 root@nemesis.os-hackers.jp:/root/rpi/build/work/obj/arm.armv6/root/rpi/build/work/src/sys/RPI-B-VIMAGE arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: init without driver. CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536866816 (511 MB) avail memory = 498728960 (475 MB) WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. random: initialized kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x20000000-0x20ffffff on ofwbus0 intc0: mem 0xb200-0xb3ff on simplebus0 systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 bcmwd0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0 gpio0: ACT LED at gpio0, pin 16 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 16 on gpiobus0 iichb0: mem 0x205000-0x20501f irq 61 on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f irq 61 on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x204000-0x20401f irq 62 on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0xb880-0xb8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x300000-0x3000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x980000-0x99ffff irq 17 on simplebus0 usbus0 on dwcotg0 fb0: on ofwbus0 simplebus1: on ofwbus0 simplebus1: could not get ranges device_attach: simplebus1 attach returned 6 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled mmcsd0: 2GB at mmc0 25.0MHz/1bit/65535-block fb0: 656x416(0x0@0,0) 16bpp fb0: pitch 1312, base 0x5f005000, screen_size 545792 fbd0 on fb0 VT: initialize with new VT driver "fb". random: unblocking device. Root mount waiting for: usbus0 uhub1: 5 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/ufs/root20140725 [rw,noatime]... smsc0: chip 0xec00, rev. 0002 WARNING: / was not properly dismounted miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:50:ce:e0 warning: no time-of-day clock registered, system time will not be set accurately gpio0: tern on ACT LED smsc0: chip 0xec00, rev. 0002 ----Next_Part(Sat_Jul_26_13_09_09_2014_456)---- From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:29:31 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ED5CE2F for ; Sat, 26 Jul 2014 04:29:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 768A021BE for ; Sat, 26 Jul 2014 04:29:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6Q4TVYv036137 for ; Sat, 26 Jul 2014 04:29:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 183740] mutex on some arm hardware requires dcache enabled Date: Sat, 26 Jul 2014 04:29:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:29:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183740 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ian@FreeBSD.org Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 04:35:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4E32FA6 for ; Sat, 26 Jul 2014 04:35:35 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C6F82288 for ; Sat, 26 Jul 2014 04:35:35 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6Q4ZZef027323 for ; Sat, 26 Jul 2014 04:35:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 187223] omap4 clock frequency computation overflow Date: Sat, 26 Jul 2014 04:35:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 04:35:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187223 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ian@FreeBSD.org Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 06:16:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B23FB37F for ; Sat, 26 Jul 2014 06:16:25 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 775CD2A55 for ; Sat, 26 Jul 2014 06:16:25 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z60so6272805qgd.27 for ; Fri, 25 Jul 2014 23:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=tqRYnuDvteU+FbJKtWxpyRiN6s1ZE74/+tFSOLftNpM=; b=RgSf6H4lJ9Odx2IIiVJNenGBjqf8R+43yxptIs9obZgfW43ONDFRgKH/vIQW5uTF1R 9cpPOe/I3CQA14PfbvPJi9aPDjRyD+GqcKd3aZiPXVODH6Iq5JeEQ6KiuLvk1JWtAAh2 1tNf9dX714909tr8+o8kHftxKHRnAdIvTqeqIRxusjDHu8GNUubROqdH0ZgxBc6NQv0e S7eUt2Xkz/XMY7l0fUapemv/7eLqgfzvG1oy7Kh6EGyUgrRbshODxxwtuXEA+GbqkbfX uZFi+4ZLdZgOPg0IOmV2DndHIBaJcYWkl0oIN2oOhkT2zMvG9/FeAxWZXTKll8HxkYU0 T2ow== MIME-Version: 1.0 X-Received: by 10.224.171.197 with SMTP id i5mr35520538qaz.55.1406355384518; Fri, 25 Jul 2014 23:16:24 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 25 Jul 2014 23:16:24 -0700 (PDT) Date: Fri, 25 Jul 2014 23:16:24 -0700 X-Google-Sender-Auth: 00XYLtvneCaM6IpgBBChhPSLHaA Message-ID: Subject: what's the updated command(s) to build a toolchain for r-pi! From: Adrian Chadd To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:16:25 -0000 Hi! I'm about to build an updated raspberry pi image from FreeBSD-HEAD but I've noticed the cross compiler toolchain again requires a new set of parameters. So, assuming I'm starting from scratch (and just assume I'm doing it in a jail, so there's no existing toolchain to interfere) - what's the correct way to build the cross-dev toolchain so it'll work for crochet? Thanks! -a From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 06:24:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A102462; Sat, 26 Jul 2014 06:24:44 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 651352AEF; Sat, 26 Jul 2014 06:24:43 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 037A378AB7; Fri, 25 Jul 2014 23:24:43 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 24091-09; Fri, 25 Jul 2014 23:24:42 -0700 (PDT) Received: from [10.8.0.10] (unknown [10.8.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 921D778AB2; Fri, 25 Jul 2014 23:24:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: what's the updated command(s) to build a toolchain for r-pi! From: Jordan Hubbard In-Reply-To: Date: Fri, 25 Jul 2014 23:24:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:24:44 -0000 On Jul 25, 2014, at 11:16 PM, Adrian Chadd wrote: > So, assuming I'm starting from scratch (and just assume I'm doing it > in a jail, so there's no existing toolchain to interfere) - what's the > correct way to build the cross-dev toolchain so it'll work for > crochet? I was going to ask that too. On -current, the crochet instructions = don=92t actually work since the GCC xdev build blows up. Conversely, = the clang xdev build works, but then crochet can=92t find the compiler = it=92s looking for and it blows up there. I=92m reduced to building = world on the RPI itself. 22 hours and counting. ;-) - Jordan From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 06:37:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78DC4864 for ; Sat, 26 Jul 2014 06:37:37 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FAF02BB4 for ; Sat, 26 Jul 2014 06:37:37 +0000 (UTC) Received: from zeppelin.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s6Q6bSx3019548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 25 Jul 2014 23:37:29 -0700 Message-ID: <53D34CA8.4040009@freebsd.org> Date: Fri, 25 Jul 2014 23:37:28 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: what's the updated command(s) to build a toolchain for r-pi! References: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> In-Reply-To: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYzZ0B/qMICdtg9Ry8/dbidxEEhKdtI9c9yotVluUvnnTLJJL0sbcrhTfbF9mmcuTomh1DnYJPoJrAvQYlfYuN5UntUlFY6wSU= X-Sonic-ID: C;cA4gUI8U5BGpWLCEoK8kYw== M;Yr3xUI8U5BGpWLCEoK8kYw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:37:37 -0000 On 07/25/14 23:24, Jordan Hubbard wrote: > On Jul 25, 2014, at 11:16 PM, Adrian Chadd wrote: > >> So, assuming I'm starting from scratch (and just assume I'm doing it >> in a jail, so there's no existing toolchain to interfere) - what's the >> correct way to build the cross-dev toolchain so it'll work for >> crochet? > I was going to ask that too. On -current, the crochet instructions don’t actually work since the GCC xdev build blows up. Conversely, the clang xdev build works, but then crochet can’t find the compiler it’s looking for and it blows up there. I’m reduced to building world on the RPI itself. 22 hours and counting. ;-) > > - Jordan > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Why do you need the xdev toolchain for building world? Just make buildworld TARGET=arm TARGET_ARCH=armv6 will do the trick. -Nathan From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 06:46:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A59DAAE0; Sat, 26 Jul 2014 06:46:14 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 832172C5E; Sat, 26 Jul 2014 06:46:13 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 1A31C78C1D; Fri, 25 Jul 2014 23:46:13 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 27390-09; Fri, 25 Jul 2014 23:46:12 -0700 (PDT) Received: from [10.8.0.10] (unknown [10.8.0.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id 610F978C19; Fri, 25 Jul 2014 23:46:11 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: what's the updated command(s) to build a toolchain for r-pi! From: Jordan Hubbard In-Reply-To: <53D34CA8.4040009@freebsd.org> Date: Fri, 25 Jul 2014 23:46:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E6D5D2B-5808-463F-B3D8-595030B2E285@mail.turbofuzz.com> References: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> <53D34CA8.4040009@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:46:14 -0000 On Jul 25, 2014, at 11:37 PM, Nathan Whitehorn = wrote: > Why do you need the xdev toolchain for building world? Just make = buildworld TARGET=3Darm TARGET_ARCH=3Darmv6 will do the trick. Sorry, I was being a bit too vague there I see. I either use crochet = (or the non-crochet tools, since crochet is broken for me right now) to = create bootable .img=92s that I can then simply copy to an SD / CF card = and boot on the rpi or, as a distinct second choice, I use the rpi to = self-host its updating process by building on it. You=92re right (and = it hadn=92t really occurred to me) that I could also just do the = buildworld / buildkernel on an intel box and then mount /usr/obj and do = the installworld / installkernel on the rpi. It=92s still no = substitute for crochet in creating entire new images, but certainly = better than nothing, and I guess I could always update the image = in-place and then copy it back the other way for cloning purposes. Hmmm. Thanks for the suggestion. :) That will save me some time. - Jordan From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 06:48:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D136AB57; Sat, 26 Jul 2014 06:48:05 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81BC02C6E; Sat, 26 Jul 2014 06:48:05 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id k15so5481631qaq.24 for ; Fri, 25 Jul 2014 23:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WfA9cAOQ77qE3ii6GoYktT2PwaJp2BRPOohfZEUBmio=; b=hyhkHtiCGkHhXoWwqaLlpIhS9524n9RINnbIMUBLEWiOfdH22FtPDLFGK8BVIuuw7q jy2/xkx51VR1ND5nMoZBY+TqUlzqcadlzW61gKDgio2eHzyCt5Ts/oJt+prvwRR4OuOB RqF780NjpMkbjvYce7DvXM8/0soo0CcJYweRGyEHQWlUJ5VbiizBoAkM5LSP1PbfSHqd MxmeShRCd0bc7VrHxRlxgX1gb3xQ8hRkIh6DleNbofb2ovYjiFiqnBJBdntrTFv/j8tW 5eCoQgddmoLcXxPlBPLtbpc4bm+LX0aFdGcgcESUn4SUbdkdLuUxr9b4QNhE+3iKxa4/ /jaA== MIME-Version: 1.0 X-Received: by 10.140.107.4 with SMTP id g4mr21771684qgf.100.1406357284609; Fri, 25 Jul 2014 23:48:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 25 Jul 2014 23:48:04 -0700 (PDT) In-Reply-To: <53D34CA8.4040009@freebsd.org> References: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> <53D34CA8.4040009@freebsd.org> Date: Fri, 25 Jul 2014 23:48:04 -0700 X-Google-Sender-Auth: _ndrJQaHyf9Vlxu9IafP-ecDrHc Message-ID: Subject: Re: what's the updated command(s) to build a toolchain for r-pi! From: Adrian Chadd To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:48:05 -0000 On 25 July 2014 23:37, Nathan Whitehorn wrote: > > On 07/25/14 23:24, Jordan Hubbard wrote: >> >> On Jul 25, 2014, at 11:16 PM, Adrian Chadd wrote: >> >>> So, assuming I'm starting from scratch (and just assume I'm doing it >>> in a jail, so there's no existing toolchain to interfere) - what's the >>> correct way to build the cross-dev toolchain so it'll work for >>> crochet? >> >> I was going to ask that too. On -current, the crochet instructions don= =E2=80=99t >> actually work since the GCC xdev build blows up. Conversely, the clang = xdev >> build works, but then crochet can=E2=80=99t find the compiler it=E2=80= =99s looking for and >> it blows up there. I=E2=80=99m reduced to building world on the RPI its= elf. 22 >> hours and counting. ;-) >> >> - Jordan >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> > > Why do you need the xdev toolchain for building world? Just make buildwor= ld > TARGET=3Darm TARGET_ARCH=3Darmv6 will do the trick. > -Nathan because we're using crochet, so we don't have to build: * uboot * the right filesystem layout to figure out how to get the boot pieces to be recognised; * put the right boot pieces in the right spot so the pi bootloader picks it= up; * get the right combination of things to generate a useful filesystem image= . So that's why your instructions by themselves aren't enough. -a From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 18:24:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B752747A for ; Sat, 26 Jul 2014 18:24:09 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B3C323F1 for ; Sat, 26 Jul 2014 18:24:09 +0000 (UTC) Received: from macbook.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id AACF5762; Sat, 26 Jul 2014 14:24:01 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: dmesg on RaspberryPi Type B+ From: Paul Mather In-Reply-To: <20140726.130909.1154868204943313876.shigeru@os-hackers.jp> Date: Sat, 26 Jul 2014 14:24:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6201512C-2BD9-46D6-B093-317E5A2F0171@gromit.dlib.vt.edu> References: <20140726.130909.1154868204943313876.shigeru@os-hackers.jp> To: YAMAMOTO Shigeru X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 18:24:09 -0000 On Jul 26, 2014, at 12:09 AM, YAMAMOTO Shigeru = wrote: >=20 > Hi, all, >=20 > I get a New RaspberryPi, RaspberryPi Type B+. >=20 > I make new SD image and I test it on RaspberryPi Type B+. > There is no problem. > My SD images is at = http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20140725/raspbe= rry-pi/ >=20 > Next, I test newest SD image at > = http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0/Fre= eBSD-11.0-CURRENT-arm-armv6-RPI-B-20140701-r268111.img.bz2. > It can't detect USB Ethernet device. As I understand it, the Raspberry Pi Model B+ has more USB ports and=20 uses a slightly different USB controller to the regular Model A and=20 Model B. I know Linux Raspberry Pi distributions have required updates=20= to run on the Model B+. I guess FreeBSD will need a tweak, too. Cheers, Paul. > It seems me to need change firmware to newer at, > https://github.com/raspberrypi/firmware >=20 > Thanks, > --- > YAMAMOTO Shigeru > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #0 r269079M: Fri Jul 25 13:39:57 JST 2014 > = root@nemesis.os-hackers.jp:/root/rpi/build/work/obj/arm.armv6/root/rpi/bui= ld/work/src/sys/RPI-B-VIMAGE arm > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > VT: init without driver. > CPU: ARM1176JZ-S rev 7 (ARM11J core) > Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext > WB enabled LABT branch prediction enabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory =3D 536866816 (511 MB) > avail memory =3D 498728960 (475 MB) > WARNING: VIMAGE (virtualized network stack) is a highly experimental = feature. > random: initialized > kbd0 at kbdmux0 > ofwbus0: > simplebus0: mem = 0x20000000-0x20ffffff on ofwbus0 > intc0: mem 0xb200-0xb3ff on simplebus0 > systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on = simplebus0 > Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 > Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 > bcmwd0: mem 0x10001c-0x100027 on simplebus0 > gpio0: mem 0x200000-0x2000af irq = 57,59,58,60 on simplebus0 > gpio0: ACT LED at gpio0, pin 16 > gpio0: read-only pins: 46,47,48,49,50,51,52,53. > gpio0: reserved pins: 48,49,50,51,52,53. > gpioc0: on gpio0 > gpiobus0: on gpio0 > gpioled0: at pin(s) 16 on gpiobus0 > iichb0: mem 0x205000-0x20501f irq 61 on = simplebus0 > iicbus0: on iichb0 > iic0: on iicbus0 > iichb1: mem 0x804000-0x80401f irq 61 on = simplebus0 > iicbus1: on iichb1 > iic1: on iicbus1 > spi0: mem 0x204000-0x20401f irq 62 on = simplebus0 > spibus0: on spi0 > bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff = irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 > mbox0: mem 0xb880-0xb8bf irq 1 on = simplebus0 > sdhci_bcm0: mem 0x300000-0x3000ff irq = 70 on simplebus0 > mmc0: on sdhci_bcm0 > uart0: mem 0x201000-0x201fff irq 65 on = simplebus0 > uart0: console (115200,n,8,1) > dwcotg0: mem 0x980000-0x99ffff = irq 17 on simplebus0 > usbus0 on dwcotg0 > fb0: on ofwbus0 > simplebus1: on ofwbus0 > simplebus1: could not get ranges > device_attach: simplebus1 attach returned 6 > Timecounters tick every 10.000 msec > usbus0: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on = usbus0 > uhub0: 1 port with 1 removable, self powered > ugen0.2: at usbus0 > uhub1: on usbus0 > uhub1: MTT enabled > mmcsd0: 2GB at mmc0 = 25.0MHz/1bit/65535-block > fb0: 656x416(0x0@0,0) 16bpp > fb0: pitch 1312, base 0x5f005000, screen_size 545792 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > random: unblocking device. > Root mount waiting for: usbus0 > uhub1: 5 ports with 4 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0: on usbus0 > Trying to mount root from ufs:/dev/ufs/root20140725 [rw,noatime]... > smsc0: chip 0xec00, rev. 0002 > WARNING: / was not properly dismounted > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:50:ce:e0 > warning: no time-of-day clock registered, system time will not be set = accurately > gpio0: tern on ACT LED > smsc0: chip 0xec00, rev. 0002 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Jul 26 21:38:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38164414 for ; Sat, 26 Jul 2014 21:38:49 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF3B12402 for ; Sat, 26 Jul 2014 21:38:48 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id tr6so5133705ieb.32 for ; Sat, 26 Jul 2014 14:38:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HsJrwFx0LBPSxn0tJlR8N+J9+i0PM+r56SnJu99jUPM=; b=hS2TQzE5IsJbikmmhTSqerb0ssdmA5pghoEid7Qyt+6doWlbU9LpQwnW6Veqttj2HD dINdS0cxQ1oyQzbJ4y1J9pCUQBiPu3WN7yrAD/F7N/1X/IuAsDI3n2gPLRQOLjM4P6zF Kow7nsOZI1CTOX+x/AjM/IXZsfp4GfsPghn6m1EYjz6wrpb4wgU8lZU98n0oBtd3JHBJ lxQMdMkyqlZtNR5+AcuVBkC/spepZ9Xe2sR4BMxpELuHD0Yl0Z/dlR1xVTE7b0eKy2NS SuXVhT7KMHDhWBMOGP9P4RgX5m8ic6vrX/1mCAFNw9VXFzua+UHickxyoee0sF09q/6R S/qw== X-Gm-Message-State: ALoCoQnK5J9SaTA9DD1v7OCK28ipaXl2s4b2jp0PEQgphBZDZ0On3etyAPAYQXRZmdwGWMdJFuR4 X-Received: by 10.43.140.129 with SMTP id ja1mr30968203icc.54.1406410722745; Sat, 26 Jul 2014 14:38:42 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id k5sm9809668igx.12.2014.07.26.14.38.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 14:38:42 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5717808E-C7D4-4643-A530-34D299B88440"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: what's the updated command(s) to build a toolchain for r-pi! From: Warner Losh In-Reply-To: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> Date: Sat, 26 Jul 2014 15:38:44 -0600 Message-Id: <0174E13C-EDC9-43D9-9552-5736A0622419@bsdimp.com> References: <538542CC-D053-4904-AE6F-0C76D946F971@mail.turbofuzz.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 21:38:49 -0000 --Apple-Mail=_5717808E-C7D4-4643-A530-34D299B88440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 26, 2014, at 12:24 AM, Jordan Hubbard = wrote: >=20 > On Jul 25, 2014, at 11:16 PM, Adrian Chadd wrote: >=20 >> So, assuming I'm starting from scratch (and just assume I'm doing it >> in a jail, so there's no existing toolchain to interfere) - what's = the >> correct way to build the cross-dev toolchain so it'll work for >> crochet? >=20 > I was going to ask that too. On -current, the crochet instructions = don=92t actually work since the GCC xdev build blows up. Conversely, = the clang xdev build works, but then crochet can=92t find the compiler = it=92s looking for and it blows up there. I=92m reduced to building = world on the RPI itself. 22 hours and counting. ;-) xdev is just used for u-boot build. Did you file a bug report with the maintainer of xdev? I happen to know = he likes you and might do something to fix specific problems brought to = his attention :) Warner --Apple-Mail=_5717808E-C7D4-4643-A530-34D299B88440 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT1B/lAAoJEGwc0Sh9sBEAenkP/2g1ank3JZ2pwi2nZU2pLlXi s6UFrkNQv2vtWkrTSoL547qJYXFX8SxFn6SB8dcrD8OaBY0o+NutpwoZ3GC0pBVM GZ4HmjeXVnGlbDgxaJArG0+cW0nVYPUhhQknsws6x4ADPqR1Ph6TNOyqy8xYc5cJ U2tHE7X6rsyoddtZJ5pKlqQjF4mttqb58/OaTWW45dOuQsO9BRuusQUcBRUaqp/H 9AizDr4LjX2uwnOQcgDb6JgHPtEk6JqFsMUyiHZqoyf8jkNWpl4B5C9k/9k/Dpfy /bpthnww2o40Ncof1n3LpD71gIjodjNY76o75NRtKJDMvprFqGInHwU776lui7/N OTXAqhcvQTPGjulPO4U5CcKlP1QIp09LrMlKE7x9BTmq69i7KCKUz+j+RRBf8Qja eDRbqoVlE0hnR29HF//ZtiX+/1udYKMIF9OfwEo7Q8DRxG2OwMPtTMCovF3BWDrj rJFKu6oofkWqG47tdTTUpKJQJfnPPaqA1TYVGUdjcCeXLhd0Gc+yf9+XHh+Qx2oQ O2XNz4jxJE9W7SX8nfejf76aovxFdlPK+EEP0GLF/6aY1hJCYg3zqLCVuoFuQKLP 3++1JbADrQBN4SRn079IE5gOnN4y+AXcI+axgz8596zGtrZK82mWX2OanFmEUR6B UIDZfMi0ZJ5vUDH6os3s =ToA+ -----END PGP SIGNATURE----- --Apple-Mail=_5717808E-C7D4-4643-A530-34D299B88440--