From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 01:47:50 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EAD5BE5B; Mon, 21 Jan 2013 01:47:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 485FF98; Mon, 21 Jan 2013 01:47:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0L1lj39069089; Mon, 21 Jan 2013 03:47:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0L1lj39069089 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0L1ljGk069088; Mon, 21 Jan 2013 03:47:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 03:47:45 +0200 From: Konstantin Belousov To: Hongli Lai Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121014745.GD2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e3HNah56eoWqGn2Q" Content-Disposition: inline In-Reply-To: <201301201652.r0KGq0d1042817@red.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@freebsd.org, pfg@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 01:47:51 -0000 --e3HNah56eoWqGn2Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 20, 2013 at 04:52:00PM +0000, Hongli Lai wrote: >=20 > >Number: 175453 > >Category: standards > >Synopsis: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-standards > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun Jan 20 17:00:00 UTC 2013 > >Closed-Date: > >Last-Modified: > >Originator: Hongli Lai > >Release: 9.1-RELEASE > >Organization: > Phusion > >Environment: > FreeBSD freebsd9 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 0= 9:23:10 UTC 2012 =20 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > >Description: > C++ code is not able to catch std::bad_cast exceptions, even though it sh= ould. If a dynamic_cast is within a try-catch block, then that block fails = to catch std::bad_cast, and the program crashes with an uncaught exception = as a result. >=20 > I've attached a reproducible test case. You can also find it at http://fo= rums.freebsd.org/showthread.php?p=3D205804#post205804 and http://stackoverf= low.com/questions/14413703/why-does-catching-stdbad-cast-not-work-on-freebs= d-9. The code is compiled with the following GCC version: >=20 > $ gcc -v > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] >=20 > FreeBSD 9.1 seems to be the only platform on which this bug appears. The = code works as expected on Linux and OS X. According to a commenter, FreeBSD= 9.0 works as expected too. According to another commenter the code fails o= n FreeBSD 9.1 with Clang too. > >How-To-Repeat: > See attached C++ program. > >Fix: >=20 >=20 > Patch attached with submission follows: >=20 > #include > #include > #include >=20 > class foo { > public: > virtual ~foo() {} > }; >=20 > class bar: public foo { > public: > int val; > bar(): val(123) {} > }; >=20 > static void > cast_test(const foo &f) { > try { > const bar &b =3D dynamic_cast(f); > printf("%d\n", b.val); > } catch (const std::bad_cast &) { > printf("bad cast\n"); > } > } >=20 > int main() { > foo f; > cast_test(f); > return 0; > } >=20 Confirmed, and it seems that the culprit is libstdc++. At least replacing the system libstdc++.so.6 with the library from the stock build of gcc 4.7.2 (without touching libgcc_s.so.1) makes the catch operator working. --e3HNah56eoWqGn2Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/J5AAAoJEJDCuSvBvK1BI5UP/2AEce74RrFLw7wirML0bt5w MaO0BP9Zb6ShKup60ON3oM3KJOjj0lL6mACQ7AU7mWic77Gh3Z0KOcUNqOhhdrfe bFcc/2eFAPE4nN82GCTJzjqhBeZdPzTqHKP7TTIqP9PWRhVzErS4Kk8BbY0ySF0E MsuEGVj75uIGkpopNYN4b9t+4iMVyR+BClnfwJCf/1jBeCCml3kD0gR5eVRV08Zw E8yO0zPKya1f0oXiT5Ks9SO8b1iXwtgksEagZdPeCobLfnG9Wo7vOP/fojnQTjJl dzWwz/vWmZlOo0YjpzEK3H1q+6WPXzGo4yXcx9uhLGZOufMmTJBzL/tdk2A3PCB/ UrEuJ7fRmn4gHfmpWMgQ5L8wClytMh7wvPUNL54Dws8mJifewISqKr9wFrR3ugUT YbzFGMhSgimOF1Xpvyqc9QXKd6tvPgs/YHojcannTPWk6rXtNu4zyTgwoxbRO6SM d4V5i+i2C4UvW/5YMZpmMFCY9v7cUUoqkkiREoY/53/6NDckENn7aTs04DebM4zw 2Jo2nmBOphVd54nE5i3OqhfjTyB2ssCkvNfviO6RmzQnMhHbWr9b0FjhDjfgHOam +lUlVvirHbBR3HAzBn5vPSYWi6XTJI0oCeiXopAwVQdyMUxXOCigkwNpqZ9TiZLR XmCeH4endI7u3vofi+KM =89Rf -----END PGP SIGNATURE----- --e3HNah56eoWqGn2Q-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 04:08:31 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDCC2883 for ; Mon, 21 Jan 2013 04:08:31 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by mx1.freebsd.org (Postfix) with SMTP id 7B1E0857 for ; Mon, 21 Jan 2013 04:08:31 +0000 (UTC) Received: from [98.139.212.145] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 04:08:22 -0000 Received: from [98.139.212.223] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 04:08:22 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 21 Jan 2013 04:08:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 273789.36724.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 75047 invoked by uid 60001); 21 Jan 2013 04:08:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358741301; bh=/s7RwNFM9dbxqvq+0mpWxjJcO1X4IOWKF8pVcT75pyw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VAqRm6r2Uikm0R8aHr94LAPgoIUg3u+CEwz0Z+ng1Km2lMB8IDQNxTXxu7/rtMLUevqsXD1HQPtlmNGNZDnViilVaeqI7COI0R7Fens4d1Tjiou2/Pl8/k+PgjGQzOYJ8Ka/V+FFRrumBro1d5ZrIqq27lXs2oQ7CrqKwPTGkCc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fYd7fwzwgIg1aHk/IriTYaDePmXIPANEZOy5alIalRVuofbq9gTotoucWN5kiNHU+fFyhE8xZPh2I2tVBf68z6luyDDWFrF5eTJWizHQgbgu6JxEa9RIXGDxmM9Iym/xTRv6c/AD45+TieV/zv3W1I1UOxmbiqdJI3IbOqXATnE=; X-YMail-OSG: hK1K6X4VM1nkUwjPAo3InOJIdNIuvCVpZ5kIIGu49noMr2w GdSishLnukxtdr2Cj4RYVRVAGxM.3Lwgn16bfP.auzA.eOq3TyrB5Bx0mIEs zNJHx_yzCfRIaMd0APpJDkxVnIDkwktz60NqdHT5y5TZZS9l_WlSzEE6fzlf QRYuY.1oaNbyEAE5MYaFnhx6tcnw7qMYxxXvT6G8K67Qjoj4SNG3YRv7Y34T ZFAZivKzHCH2JgWJeGhMBjszNge1SdtcF3pxJD72OgBXQEy9qAkPSJNWejLK ogCZoMYZfD7ZQNm57SBDuElFcFgAgM3OiYw8_HXdkdS0fHKwEHWcJHrONCYi fZAEUmJcGuSzPvvKxn1B6Od9tyzagYA_63A1f74RjJ9BpeH0xTaE3qBn34h7 ltAdJT5LIVIecvMSIQ6.VKab.AIHLfWvvd2RTsgHY4hm3X82335wSZSXcv22 Am5Kdq1M55Syc2c5E6v9BC0uc6S3dt7Z8ScKZBSmmaHTrWiaZeZI6Xcxox1n YqLgZ9vNrXKTupgn2evxzCPTyvr2eNPe.DFf3Q0ENCklADLygs2aKP.bMwRc KVboiMT9icERY4ZG4sCzmWhPmXkOqP.6x02ihrS9u54R7ihX8o6TYmrYc_0t IgArbOmxmo3SpL6UV.N5eDVPEAqiTImGA4RCw4ZU3Y7gds5lVwKXywNWNzfY b4OvRpWxudI9rPvvD4sleaxhHCoJIN3E3NAw9D0Gb7J.wpTbNCALw9Grs.4x vpS5mRMmAhG1b6liSvtrbilPFCH4E Received: from [200.118.157.7] by web162102.mail.bf1.yahoo.com via HTTP; Sun, 20 Jan 2013 20:08:21 PST X-Rocket-MIMEInfo: 001.001, CgoKCi0tLS0tIE1lc3NhZ2dpbyBvcmlnaW5hbGUgLS0tLS0KPiBEYTogS29uc3RhbnRpbiBCZWxvdXNvdsKgCj4gCj4gT24gU3VuLCBKYW4gMjAsIDIwMTMgYXQgMDQ6NTI6MDBQTSArMDAwMCwgSG9uZ2xpIExhaSB3cm90ZToKPj4gCj4.ICA.TnVtYmVyOsKgIMKgIMKgIMKgICAxNzU0NTMKPj4gID5DYXRlZ29yeTrCoCDCoCDCoCAgc3RhbmRhcmRzCj4.ICA.U3lub3BzaXM6wqAgwqAgwqAgIENhdGNoaW5nIEMrKyBzdGQ6OmJhZF9jYXN0IGRvZXNuJ3Qgd29yayBpbiBGcmVlQlNEIAo.IDkuMQo.PiAgPkNvbmYBMAEBAQE- X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.130.494 References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> Message-ID: <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> Date: Sun, 20 Jan 2013 20:08:21 -0800 (PST) From: Pedro Giffuni Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 To: Konstantin Belousov , Hongli Lai In-Reply-To: <20130121014745.GD2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "toolchain@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Pedro Giffuni List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 04:08:32 -0000 =0A=0A=0A=0A----- Messaggio originale -----=0A> Da: Konstantin Belousov=A0= =0A> =0A> On Sun, Jan 20, 2013 at 04:52:00PM +0000, Hongli Lai wrote:=0A>> = =0A>> >Number:=A0 =A0 =A0 =A0 175453=0A>> >Category:=A0 =A0 =A0 standar= ds=0A>> >Synopsis:=A0 =A0 =A0 Catching C++ std::bad_cast doesn't work in = FreeBSD =0A> 9.1=0A>> >Confidential:=A0 no=0A>> >Severity:=A0 =A0 =A0 n= on-critical=0A>> >Priority:=A0 =A0 =A0 low=0A>> >Responsible:=A0 =A0 fre= ebsd-standards=0A>> >State:=A0 =A0 =A0 =A0 =A0 open=0A>> >Quarter:=A0 =A0= =A0 =A0 =0A>> >Keywords:=A0 =A0 =A0 =0A>> >Date-Required:=0A>> >Class:= =A0 =A0 =A0 =A0 =A0 sw-bug=0A>> >Submitter-Id:=A0 current-users=0A>> >Ar= rival-Date:=A0 Sun Jan 20 17:00:00 UTC 2013=0A>> >Closed-Date:=0A>> >Las= t-Modified:=0A>> >Originator:=A0 =A0 Hongli Lai=0A>> >Release:=A0 =A0 = =A0 =A0 9.1-RELEASE=0A>> >Organization:=0A>> Phusion=0A>> >Environment:= =0A>> FreeBSD freebsd9 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec= =A0 4 =0A> 09:23:10 UTC 2012=A0 =A0 =0A>> root@farrell.cse.buffalo.edu:/us= r/obj/usr/src/sys/GENERIC=A0 amd64=0A>> >Description:=0A>> C++ code is no= t able to catch std::bad_cast exceptions, even though it =0A> should. If a = dynamic_cast is within a try-catch block, then that block fails to =0A> cat= ch std::bad_cast, and the program crashes with an uncaught exception as a = =0A> result.=0A>> =0A>> I've attached a reproducible test case. You can al= so find it at =0A> http://forums.freebsd.org/showthread.php?p=3D205804#post= 205804 and =0A> http://stackoverflow.com/questions/14413703/why-does-catchi= ng-stdbad-cast-not-work-on-freebsd-9. =0A> The code is compiled with the fo= llowing GCC version:=0A>> =0A>> $ gcc -v=0A>> Using built-in specs.=0A>> = Target: amd64-undermydesk-freebsd=0A>> Configured with: FreeBSD/amd64 sys= tem compiler=0A>> Thread model: posix=0A>> gcc version 4.2.1 20070831 pat= ched [FreeBSD]=0A>> =0A>> FreeBSD 9.1 seems to be the only platform on whi= ch this bug appears. The =0A> code works as expected on Linux and OS X. Acc= ording to a commenter, FreeBSD 9.0 =0A> works as expected too. According to= another commenter the code fails on FreeBSD =0A> 9.1 with Clang too.=0A>> = >How-To-Repeat:=0A>> See attached C++ program.=0A>> >Fix:=0A>> =0A>> =0A= >> Patch attached with submission follows:=0A>> =0A>> #include =0A>> #include =0A>> #include =0A>> =0A>> class foo = {=0A>> public:=0A>> =A0 =A0 virtual ~foo() {}=0A>> };=0A>> =0A>> class = bar: public foo {=0A>> public:=0A>> =A0 =A0 int val;=0A>> =A0 =A0 bar():= val(123) {}=0A>> };=0A>> =0A>> static void=0A>> cast_test(const foo &f)= {=0A>> =A0 =A0 try {=0A>> =A0 =A0 =A0 =A0 const bar &b =3D dynamic_cast<= const bar &>(f);=0A>> =A0 =A0 =A0 =A0 printf("%d\n", b.val);=0A>> =A0 =A0 = } catch (const std::bad_cast &) {=0A>> =A0 =A0 =A0 =A0 printf("bad cast\n= ");=0A>> =A0 =A0 }=0A>> }=0A>> =0A>> int main() {=0A>> =A0 =A0 foo f;= =0A>> =A0 =A0 cast_test(f);=0A>> =A0 =A0 return 0;=0A>> }=0A>> =0A> Conf= irmed, and it seems that the culprit is libstdc++. At least replacing=0A> t= he system libstdc++.so.6 with the library from the stock build of gcc=0A> 4= .7.2 (without touching libgcc_s.so.1) makes the catch operator working.=0A>= =0A=0AConfirmed,=0A=A0=0AThe problem is actually not in any of the code up= dates to libstdc++ but=0Ain the way libstdc++ is configured/build since 9.0= .=0A=0AReverting the changes in=A0stable/9/gnu/lib/libstdc up to r229037 th= ings work=0Ajust fine.=0A=0AI suspect the culprit is r233749 and subsequent= changes to build libstdc++=0Aas a filter library for libsupc++.=0A=0AThis = also seems similar ot PR=A0kern/171610.=0A=0APedro. From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 04:49:23 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7843D13D; Mon, 21 Jan 2013 04:49:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DCDE8968; Mon, 21 Jan 2013 04:49:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0L4nD7W090780; Mon, 21 Jan 2013 06:49:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0L4nD7W090780 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0L4nCvs090779; Mon, 21 Jan 2013 06:49:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 06:49:12 +0200 From: Konstantin Belousov To: Pedro Giffuni Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121044912.GE2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WeoCK3UN7lwjrlbw" Content-Disposition: inline In-Reply-To: <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "toolchain@freebsd.org" , Hongli Lai X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 04:49:23 -0000 --WeoCK3UN7lwjrlbw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 20, 2013 at 08:08:21PM -0800, Pedro Giffuni wrote: >=20 >=20 >=20 >=20 > ----- Messaggio originale ----- > > Da: Konstantin Belousov=9A > >=20 > > On Sun, Jan 20, 2013 at 04:52:00PM +0000, Hongli Lai wrote: > >>=20 > >> >Number:=9A =9A =9A =9A 175453 > >> >Category:=9A =9A =9A standards > >> >Synopsis:=9A =9A =9A Catching C++ std::bad_cast doesn't work in Fre= eBSD=20 > > 9.1 > >> >Confidential:=9A no > >> >Severity:=9A =9A =9A non-critical > >> >Priority:=9A =9A =9A low > >> >Responsible:=9A =9A freebsd-standards > >> >State:=9A =9A =9A =9A =9A open > >> >Quarter:=9A =9A =9A =9A=20 > >> >Keywords:=9A =9A =9A=20 > >> >Date-Required: > >> >Class:=9A =9A =9A =9A =9A sw-bug > >> >Submitter-Id:=9A current-users > >> >Arrival-Date:=9A Sun Jan 20 17:00:00 UTC 2013 > >> >Closed-Date: > >> >Last-Modified: > >> >Originator:=9A =9A Hongli Lai > >> >Release:=9A =9A =9A =9A 9.1-RELEASE > >> >Organization: > >> Phusion > >> >Environment: > >> FreeBSD freebsd9 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec= =9A 4=20 > > 09:23:10 UTC 2012=9A =9A=20 > >> root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=9A amd64 > >> >Description: > >> C++ code is not able to catch std::bad_cast exceptions, even though i= t=20 > > should. If a dynamic_cast is within a try-catch block, then that block = fails to=20 > > catch std::bad_cast, and the program crashes with an uncaught exception= as a=20 > > result. > >>=20 > >> I've attached a reproducible test case. You can also find it at=20 > > http://forums.freebsd.org/showthread.php?p=3D205804#post205804 and=20 > > http://stackoverflow.com/questions/14413703/why-does-catching-stdbad-ca= st-not-work-on-freebsd-9.=20 > > The code is compiled with the following GCC version: > >>=20 > >> $ gcc -v > >> Using built-in specs. > >> Target: amd64-undermydesk-freebsd > >> Configured with: FreeBSD/amd64 system compiler > >> Thread model: posix > >> gcc version 4.2.1 20070831 patched [FreeBSD] > >>=20 > >> FreeBSD 9.1 seems to be the only platform on which this bug appears. = The=20 > > code works as expected on Linux and OS X. According to a commenter, Fre= eBSD 9.0=20 > > works as expected too. According to another commenter the code fails on= FreeBSD=20 > > 9.1 with Clang too. > >> >How-To-Repeat: > >> See attached C++ program. > >> >Fix: > >>=20 > >>=20 > >> Patch attached with submission follows: > >>=20 > >> #include > >> #include > >> #include > >>=20 > >> class foo { > >> public: > >> =9A =9A virtual ~foo() {} > >> }; > >>=20 > >> class bar: public foo { > >> public: > >> =9A =9A int val; > >> =9A =9A bar(): val(123) {} > >> }; > >>=20 > >> static void > >> cast_test(const foo &f) { > >> =9A =9A try { > >> =9A =9A =9A =9A const bar &b =3D dynamic_cast(f); > >> =9A =9A =9A =9A printf("%d\n", b.val); > >> =9A =9A } catch (const std::bad_cast &) { > >> =9A =9A =9A =9A printf("bad cast\n"); > >> =9A =9A } > >> } > >>=20 > >> int main() { > >> =9A =9A foo f; > >> =9A =9A cast_test(f); > >> =9A =9A return 0; > >> } > >>=20 > > Confirmed, and it seems that the culprit is libstdc++. At least replaci= ng > > the system libstdc++.so.6 with the library from the stock build of gcc > > 4.7.2 (without touching libgcc_s.so.1) makes the catch operator working. > >=20 >=20 > Confirmed, > =9A > The problem is actually not in any of the code updates to libstdc++ but > in the way libstdc++ is configured/build since 9.0. >=20 > Reverting the changes in=9Astable/9/gnu/lib/libstdc up to r229037 things = work > just fine. >=20 > I suspect the culprit is r233749 and subsequent changes to build libstdc++ > as a filter library for libsupc++. >=20 > This also seems similar ot PR=9Akern/171610. Yes, quite possible. AFAIR, the 'catch' code compares the exception classes by the shared object ownership. It might get confused due to filter providi= ng some symbols. But I did not investigated the cause for real. --WeoCK3UN7lwjrlbw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/MjHAAoJEJDCuSvBvK1BJpIP+wTaJ6Eu6yTeD/q9YVt77ZTn +liyii4Gvv3jMtVdYwYGddjT/bMHlCik2WznEPBfbwQEUByOEJHEHPv5NVdDjQn3 MNI8CQtnUP/bu8tR4PrWPZyChbTYezge1RrDD8/ndxfMFdjyOUXgE5vHt9BgzwB8 Qf/4IxcY5TaantPUmjuAcpmmxxmVB9kGOSStcUZowJzsHlpVAOcwyvOxGz0Pw8m6 N3fDv0R23ldaEgsEX+++Haa3Ihp9nAVdPy0NzVv8MRbv7WoVfCl7ginxBPAL53wm IAdlHrLbpC4e105EHvNHG0nm9tqlOS0XlWjlZox6wb1Yat5X77iM1LCI4ZHDftcD 8Z8vEjx3poZ6srXQHpgw6djouQIQ6NycGbAmlIQdG5NNpNBitJP0cDvf+h9dGK9i nsVwjaQRz9iPdm7TdQeHdcr75HOVoIHkce+p9PRtW63QQtYT7xRFGrlgm7G9d3aM JZppvyMIWHh7e19VHtt7MptvAJv9oXe8KWTUJYK7FWE+fgxvPJY1wTnf+GHmBK8V HM3KHiTYwgVEBR4zXIYmwVjfMtVOZAnDZf9Glecv9PnZzEQQuYlzf1LOkSSFbaQ0 vHCdztBhY4tlbDpsIJwpW0sikgQve2a5e6Jrd/62vNI8g7Bmz2b/6sXXrNUxvhPi jg2De2GhZkl7eITqmNBO =irPx -----END PGP SIGNATURE----- --WeoCK3UN7lwjrlbw-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 09:25:38 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B38C011C; Mon, 21 Jan 2013 09:25:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6B9DCA4F; Mon, 21 Jan 2013 09:25:38 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0L9PYof055065 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 09:25:35 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121044912.GE2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 09:25:36 +0000 Message-Id: References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 09:25:38 -0000 --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=koi8-r On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > Yes, quite possible. AFAIR, the 'catch' code compares the exception = classes > by the shared object ownership. It might get confused due to filter = providing > some symbols. >=20 > But I did not investigated the cause for real. I'm investigating this. It seems that the issue still appears when = using libcxxrt instead of libsupc++ with libstdc++ (the test cases work = fine with libc++ and libcxxrt), so it is likely some symbol confusion in = libstdc++. My guess would be that it's using pointer comparison for the exception = type info names and these are somehow different as a result of the = filter library mode. I'll investigate further later today. David --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/QmQAAoJEKx65DEEsqIdOdAQAK5Omjp1N0VChYAtQDwokS+R ReXZnr9WBuwr/gdS2Ws7fT3sWboiQdt04RQupaD+fatxMmT8dY2t1vrj+e+vL9OO 1Ou2dbZIOIgvYJOJKDndnTw+3UeJjCgmaONs8LDjkJtjPYx+9k5raEg1HhNEa9GF cEkj51p1pEtTWBNFKHIwDqpqACbVunR8qwEIgoiI2ZOwDzXKVTNq4VM9u2eRK4xj H3x+/fIKoQHHeQhvno5DYWhWM1NAwL8zhfn3BSHWO6/RkycyHHiV0wb5McYYJ5qq cXSV29SNhfGeLj9ctj/OkbkVPFkYG5GMVN1uaIIKL5+/bCWCJ+eQ7KBvh2oBYdYx fa/8pbeQClLfcdqa/ryongF2fjzUF+FdvSYhtX3aUy7b8rdGKRW3T1VrRdJ9ccO9 Nx60AFys0279ECPPaez2izau6z13yzA3Qg/U7zBoBzTqE+yxyD/NIJ84JV48tP3s zRYIKpsgOQROBbB/0QwK2lKLz3cRacm93WOpTTeA3Uv7O0PUj22gg2wXbEMEmfNG CL2ci78amLyxzKHltl/V4E9x/p3n7Cu8msXT5H74+uoYFU73gM5yDWDshpkkEHMU itS3JwV3hn1KH1vauWi9l7CG81tREAMSHO7Ubh4PCA56QoTF3xqNyMYasrlLI+sp 0KY2KfHdKb1v498FlDdB =WVnM -----END PGP SIGNATURE----- --Apple-Mail=_CFDA6A31-1B86-4F4C-86A7-982E749F2F09-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 16:12:04 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9DBA440F; Mon, 21 Jan 2013 16:12:04 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4D331C28; Mon, 21 Jan 2013 16:12:03 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0LGC1SF056313 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 16:12:02 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_73AF96C3-09F4-403A-82C3-F033D08744E0"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121044912.GE2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 16:12:00 +0000 Message-Id: <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 16:12:04 -0000 --Apple-Mail=_73AF96C3-09F4-403A-82C3-F033D08744E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=koi8-r On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > Yes, quite possible. AFAIR, the 'catch' code compares the exception = classes > by the shared object ownership. It might get confused due to filter = providing > some symbols. >=20 > But I did not investigated the cause for real. The issue appears to be that the libstdc++ exports a few functions[1] = that libsupc++ exports, but with different symbol versions. = Unfortunately, these are things that set handlers that are then called = from libsupc++ / libcxxrt when, for example, an exception specification = violation is encountered. I'm not sure what the solution is here. Is there some = version-script-foo that we can do to say 'filter this symbol with this = version as if it were this one with this version'? We ideally want to = keep them with the current version in libcxxrt / libsupc++, but not = introduce linker errors. =20 David [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected()= --Apple-Mail=_73AF96C3-09F4-403A-82C3-F033D08744E0 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/WjRAAoJEKx65DEEsqId6HYP/2e/PV0Ht/amvqFTJOEafsdm JHk+Uqmr0BMnspbjVXTaN0U6juEcRoDSN5EEG1St7sJ7TVn+lG9/ZqpC7MOb23/P xR7AMobZFpT19s77z68e4T3AaTkcHMuNg/85dj7QdNbQDa4QnB1o2uQyUb4LV19l QmVvKE26QTVt1BFdf04ChIovRCy/3/u+WkcN0rVKpUfcUGXic+Zsmc0FvHUDB+IT kgPMohFBXjqH2gBWJR41oiJcgedEzrCvWa4uzHXkzE/tybrUbtMnjW3ztfp1xbSp Xi2e/eJ1c/RtZhtDssJB1iX9tD0T/uda5eedtLKIucaOHP5qYcIzNu2W9xre3qnB VjQkG//ZcHy5PlUpLiY+SkiMx39U2CK57JzjCfBngcnfxoB4Suhnf1l6Nsnetyn6 VvgSx9WPowmuaIeiQvXDJo+sLj5OQabIo2gCQwxPTbU06YWPegrydMks/PwPHQXt AWiP9pkMU/HisK5YNeDOCh8rAWbULyCphuj7+aLG1ps/vs2hb15Ln3VJkLFSZdjT yjFrQztRQAmKvLhnaARc7ZFmFxrerRtaLtL5VGgfD18rboLyJfL1yCPFrjbDEJhB 94M22FFcmQQ1gtjxhh+qfiKPSCQupoagy/1ifu8hDvoU17Us40R0MM3nCaZw1QvM z9Keg+zxLcFwcaMFE7gn =BDgG -----END PGP SIGNATURE----- --Apple-Mail=_73AF96C3-09F4-403A-82C3-F033D08744E0-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 16:54:33 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E3C82FD2; Mon, 21 Jan 2013 16:54:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 85886ED4; Mon, 21 Jan 2013 16:54:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0LGsSSB069709; Mon, 21 Jan 2013 18:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0LGsSSB069709 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0LGsSv0069708; Mon, 21 Jan 2013 18:54:28 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 18:54:28 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121165427.GG2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J1ldk4ymECC/Y9sn" Content-Disposition: inline In-Reply-To: <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 16:54:34 -0000 --J1ldk4ymECC/Y9sn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 04:12:00PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: >=20 > > Yes, quite possible. AFAIR, the 'catch' code compares the exception cla= sses > > by the shared object ownership. It might get confused due to filter pro= viding > > some symbols. > >=20 > > But I did not investigated the cause for real. >=20 > The issue appears to be that the libstdc++ exports a few functions[1] tha= t libsupc++ exports, but with different symbol versions. Unfortunately, th= ese are things that set handlers that are then called from libsupc++ / libc= xxrt when, for example, an exception specification violation is encountered. >=20 > I'm not sure what the solution is here. Is there some version-script-foo= that we can do to say 'filter this symbol with this version as if it were = this one with this version'? We ideally want to keep them with the current= version in libcxxrt / libsupc++, but not introduce linker errors. =20 >=20 > David >=20 > [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected() Can you prepare the minimal isolated test case which demostrates the behaviour ? A plan would be to ask somebody to run the test on the linux. I think we must be bug-to-bug compatible with glibc in regard to the filters quirks. Gnu filters work only on the whole object scope. Solaris linkers do have per-symbol filtering, but Solaris does not implement per-symbol versioning, on the other hand. --J1ldk4ymECC/Y9sn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/XLDAAoJEJDCuSvBvK1BLSgP/ilxbTO+0sUU6miJCWTkt65Y K3DGVuMKEIC4sQeMPvt5+K3WXdGYmEyEpNAFuU3CQqAvJO+4cwPpflKFlMqzkfOB G7B2IIAtM+eyQqEL1oh6patFr3+IrF2V3n7dWYCKrXygNdbCfYxVA1Z1L00cEiD3 zPqK6fBVJT5MBx8Ny6tX3bB9ehrW24FeYCgBjI0+FvFonAPHWOUu3NA1szkMpWr7 mE6bDZhQ+eZOs/sEmS0ys9U9pVK5by+U/faLFJr0D2j1y+zxYCw/d5hedg3JgFT2 rRKEK5S13Aqwe2za/pUNVlQDoKdNRkhGQr5awN61GIl+XxSkF7yVkO15j7mL2n62 NAEaqFq4GftHWZhDhHkcn1hWAKfGfCSV9+N/USCs1HCNADWg9iGiYTjynnofd8SE 3RmiJ5aDJY5nI+R2qUCjXZuMXTlgW+iJO0ibOoyvdBsST7l6wJ+xy9kjet5k03TC d/se2Qz7/4NEI+yDI/fy29lbKYF6Cjhgs+RLThzDay8Faj0nSSDJkjTT8NVHk/20 cxgzk5bfJ/VzYYarG6A4Jm2fhSxGfQ9cPCX66h797b8bzYUJC+LohajL4WszcLt1 NCC/OWS/mn4w0u3WaCScYbWcs1KM4zKIdFlUMGefYxQucHXO8Lqb5A6GNNSsSAnE YJQHX4e+80j8IR/914dC =8VBT -----END PGP SIGNATURE----- --J1ldk4ymECC/Y9sn-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:09:34 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6CDA43F3; Mon, 21 Jan 2013 17:09:34 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8B9F71; Mon, 21 Jan 2013 17:09:33 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0LH9UcT056570 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 17:09:31 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121165427.GG2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 17:09:25 +0000 Message-Id: <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:09:34 -0000 --Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: > On Mon, Jan 21, 2013 at 04:12:00PM +0000, David Chisnall wrote: >> On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: >>=20 >>> Yes, quite possible. AFAIR, the 'catch' code compares the exception = classes >>> by the shared object ownership. It might get confused due to filter = providing >>> some symbols. >>>=20 >>> But I did not investigated the cause for real. >>=20 >> The issue appears to be that the libstdc++ exports a few functions[1] = that libsupc++ exports, but with different symbol versions. = Unfortunately, these are things that set handlers that are then called = from libsupc++ / libcxxrt when, for example, an exception specification = violation is encountered. >>=20 >> I'm not sure what the solution is here. Is there some = version-script-foo that we can do to say 'filter this symbol with this = version as if it were this one with this version'? We ideally want to = keep them with the current version in libcxxrt / libsupc++, but not = introduce linker errors. =20 >>=20 >> David >>=20 >> [1] std::set_new_handler(), std::set_terminate(), = std::set_unexpected() >=20 > Can you prepare the minimal isolated test case which demostrates the > behaviour ? A plan would be to ask somebody to run the test on the = linux. > I think we must be bug-to-bug compatible with glibc in regard to the > filters quirks. I'm not sure what you want the test case to demonstrate. I have a = reduced form of the exception test case, but it only fails for us = because of the symbol versioning issue. Moving the relevant symbols = into the same version in our libsupc++ and libcxxrt as in libstdc++ = fixes it (and is probably the right thing to do. On closer inspection = both already expose new and delete in this symbol version namespace, so = it's fine to add a few more). > Gnu filters work only on the whole object scope. Solaris linkers do > have per-symbol filtering, but Solaris does not implement per-symbol > versioning, on the other hand. If you want a simple test case for the filter behaviour, the recipe is: Symbol X in filter with version A Symbol X in filtee with version B Symbol Y in program uses symbol X Program sees version A, filtee sees version B. David= --Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/XZFAAoJEKx65DEEsqIdxZkP/0dIchz8vF2/6o6m/IKfjmyF RbbpG0t7ZmEyPjjcIiDbklYemgoxDVJEAO5tLwpzCC/sTBOHeNQwmlXOTySU8lSq Yde7JS+r0rxJkLnYvsxEp7blsdTNqTWxkR2EJpb6JBo++Op488liPtudvgaUanhy xzI00pfbkq0qxEgsvSQKj0SB5gb0PUqGQPW1xqU0CXYWF0jS9H0LIozdVmTIRi7b KUz2VsF/xjMBxpHdqISETdNYSGvbPdoWNQ6e5mlx4R17pv5sBV1zzBDVMDiMwd8v bo4LlvYDmtLEGE9OIXAhw25+VV2FbY/Blau5pgvmq4J+1oIhDnunQ2wZ2x3FBAfR LA+xSPdGfPpo3DqC7A7sRUkKWZ9PqMVNU1oE0cPdsRGnCi7xqlb9OWVnVJ0eiD0D WMFEWOM8nLiCbWNZpqKiVlaI/yaf+xzHxH3BROHGSAXIW45IXHvKtFXOU1pl0+4M MIUyQjvjGWf2wek/QAQ6YgWzWtqEI1sVM6j0bgN+ejzmpzoHeqz+bzkHhefZC6y8 +TxAoev42RETUU8knN1XyCn3KjfybdjXkLoZgcPWeU/ih+IANFGe0ykWCc3VEWpp WiueKfqK5WuiE2oDV5y9dKe1SnFGaKXF8zJ2zOhTq0yJVo6sRu72aVEcX6VHsj+3 RNb9enL8uD03DvHy7DTr =1T3L -----END PGP SIGNATURE----- --Apple-Mail=_46522E85-D084-4705-B13A-3FA77EB426FA-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:24:19 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4A326894; Mon, 21 Jan 2013 17:24:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9A6C2AC; Mon, 21 Jan 2013 17:24:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0LHOArs072913; Mon, 21 Jan 2013 19:24:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0LHOArs072913 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0LHO9BT072912; Mon, 21 Jan 2013 19:24:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 19:24:09 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121172409.GJ2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aRzsUE0Mp86t8N62" Content-Disposition: inline In-Reply-To: <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:24:19 -0000 --aRzsUE0Mp86t8N62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 05:09:25PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 16:54, Konstantin Belousov wrote: >=20 > > On Mon, Jan 21, 2013 at 04:12:00PM +0000, David Chisnall wrote: > >> On 21 Jan 2013, at 04:49, Konstantin Belousov wrote: > >>=20 > >>> Yes, quite possible. AFAIR, the 'catch' code compares the exception c= lasses > >>> by the shared object ownership. It might get confused due to filter p= roviding > >>> some symbols. > >>>=20 > >>> But I did not investigated the cause for real. > >>=20 > >> The issue appears to be that the libstdc++ exports a few functions[1] = that libsupc++ exports, but with different symbol versions. Unfortunately,= these are things that set handlers that are then called from libsupc++ / l= ibcxxrt when, for example, an exception specification violation is encounte= red. > >>=20 > >> I'm not sure what the solution is here. Is there some version-script-= foo that we can do to say 'filter this symbol with this version as if it we= re this one with this version'? We ideally want to keep them with the curr= ent version in libcxxrt / libsupc++, but not introduce linker errors. =20 > >>=20 > >> David > >>=20 > >> [1] std::set_new_handler(), std::set_terminate(), std::set_unexpected() > >=20 > > Can you prepare the minimal isolated test case which demostrates the > > behaviour ? A plan would be to ask somebody to run the test on the linu= x. > > I think we must be bug-to-bug compatible with glibc in regard to the > > filters quirks. >=20 > I'm not sure what you want the test case to demonstrate. I have a reduce= d form of the exception test case, but it only fails for us because of the = symbol versioning issue. Moving the relevant symbols into the same version= in our libsupc++ and libcxxrt as in libstdc++ fixes it (and is probably th= e right thing to do. On closer inspection both already expose new and dele= te in this symbol version namespace, so it's fine to add a few more). >=20 > > Gnu filters work only on the whole object scope. Solaris linkers do > > have per-symbol filtering, but Solaris does not implement per-symbol > > versioning, on the other hand. >=20 > If you want a simple test case for the filter behaviour, the recipe is: >=20 > Symbol X in filter with version A > Symbol X in filtee with version B > Symbol Y in program uses symbol X >=20 > Program sees version A, filtee sees version B. So can you provide self-contained test.tgz with Makefile and neccessary =2Ec files which demonstrate exactly the behaviour you see ? --aRzsUE0Mp86t8N62 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/Xm5AAoJEJDCuSvBvK1BZVMQAJZLhX886Vsh4ZhQ5CNa6Qya jYSW3YUlrSe+Xjw2+WffpwmPBMIa+1M2laLOVXb3L/IUIXVT5llXvSgRpOlyOWKV xMPOBJIGgwY6XMB/vgnuM5v7LTQkJ9LZXWz2gYjX+hwSg7uY1jgtUYHp0McI/wNK f/237EbbernBMwPS2EbhMrdXmeKkid/2loXJJPrQ1AEfX2ioqt/knjp2b2hVHayf lTFGSoJqly1c7om7Nfu5LDwmOB9+xpW0SYcWupzbv8BP+lqhs80tjMCo5N6l2Oqw FRONUFcIfXeP9tcLgzSKM9RBQXDF4UW/DKhVRh1gvxQ6BvRSkqZvh3XVLZkGQCy8 Sp3U/8nEqkVHJOBnz5Cx1n1hMKYRC9cbNsGCXJ9WGK3sKMAfsEyXtscrjwOPORyn oDMMS74YgPerMhIo5YRW56unAfEpw4QdZB5POJ7aU/3I5RilxYlnML6vUx5fQfZq xDRxFujBKwMhG8WPnLwBg6XKI7qNLFvnUbZFVj7rlH43BRXiezS0RVaj/LoIrDZk i30OL//FHMOVV7aOyE34KqiTdLNDtO1fyNgzHGWnZyksahhJWtvJZA90kqZyuivO lVilIa5rm63fgt+yBE+Mo7xcqadNffwzODJugDyAwb7sQtH8UOTmmjcdJFIsJ763 1eftPJ4Z5VIHIsl3XUTF =9qXn -----END PGP SIGNATURE----- --aRzsUE0Mp86t8N62-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:26:38 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE1C09C5; Mon, 21 Jan 2013 17:26:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 63B19C6; Mon, 21 Jan 2013 17:26:37 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0LHQZlL056946 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 17:26:36 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_66CC1499-63F1-4AB3-B4CF-CC48B76FCC07"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130121172409.GJ2522@kib.kiev.ua> Date: Mon, 21 Jan 2013 17:26:29 +0000 Message-Id: References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> <20130121172409.GJ2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:26:38 -0000 --Apple-Mail=_66CC1499-63F1-4AB3-B4CF-CC48B76FCC07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: > So can you provide self-contained test.tgz with Makefile and = neccessary > .c files which demonstrate exactly the behaviour you see ? I don't have one, this is the behaviour that I see from C++ programs = linked to libstdc++. David --Apple-Mail=_66CC1499-63F1-4AB3-B4CF-CC48B76FCC07 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJQ/XpGAAoJEKx65DEEsqIdp4gQAMKbzxfFEoyo4GecZkWhc4Qk 7nEla4K8BpOUgN+m23k4pQRjeZKXufcG7BUcTGflrl13k/3E+Yx4knACTfMLbBMo iZq6OCQityM+2f+GXu0d3bBr3VeDYyPsDxPWhgwhMSXyVNc1KTcz4Z6c3pQlJqYX PRJBDgyDNKafmnQ38uqYFxdPdzV2vvoger/B5ICvYnJZ6mB6Rf+khpJ0/ZdAze7k +D4JUdbalzSm29u0AfIIm+zebNpSgYWOwALifCm45AoS5ggKMM3UquqUWH2LrXTj MlBhhRnF2AS6h9HNJyCQF/WfcBziJ8Oauh0ech6CQ7WmEPAFgpE7wqTqWnqm03UZ iiG4FEwE79OBMKvRk6PI3asCtQtvBRDwxtJMhE/3jHcnjfB43G8Rh0XatjKyEoOc sMpKr2pP4VWirlUHbpCQBXH9UwWwgo4oQTOir/IVMkRj3kbovqu0i6sYU6tbRLph xnOAahwS9xI9AMv14IPia3wjrj4MdNYOq9+oJjo3eJqYdOZnc/IlGn9XyjgS1kmC 8tlVXdZDISh98IonOlbowiIDLdvgPw9e9ngiHXKyf1QCrEm8G8IrqTABIAHvc3gI pWiYQxhL7oT7pGSvD6WTeBMzmag8/GFbl3Dncx5jojHZof4/os96UoQ31GTn1PU3 u9l7C3abmf1yGOY9/LMq =RV58 -----END PGP SIGNATURE----- --Apple-Mail=_66CC1499-63F1-4AB3-B4CF-CC48B76FCC07-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 21 17:46:00 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1FAD066A; Mon, 21 Jan 2013 17:46:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 61DD41CD; Mon, 21 Jan 2013 17:45:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0LHjuDM075589; Mon, 21 Jan 2013 19:45:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0LHjuDM075589 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0LHjuiS075588; Mon, 21 Jan 2013 19:45:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Jan 2013 19:45:55 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 Message-ID: <20130121174555.GK2522@kib.kiev.ua> References: <201301201652.r0KGq0d1042817@red.freebsd.org> <20130121014745.GD2522@kib.kiev.ua> <1358741301.62974.YahooMailNeo@web162102.mail.bf1.yahoo.com> <20130121044912.GE2522@kib.kiev.ua> <398F1CB4-D4B0-4C21-BA05-59DDE77C5DA6@FreeBSD.org> <20130121165427.GG2522@kib.kiev.ua> <2C83B09F-5504-4848-8EB8-877305684254@FreeBSD.org> <20130121172409.GJ2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KkUfzEtIprrm0TMY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "toolchain@freebsd.org" , Hongli Lai , Pedro Giffuni X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 17:46:00 -0000 --KkUfzEtIprrm0TMY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2013 at 05:26:29PM +0000, David Chisnall wrote: > On 21 Jan 2013, at 17:24, Konstantin Belousov wrote: >=20 > > So can you provide self-contained test.tgz with Makefile and neccessary > > .c files which demonstrate exactly the behaviour you see ? >=20 > I don't have one, this is the behaviour that I see from C++ programs link= ed to libstdc++. I understand that you do not have one. Can you write it ? [This is my last mail on the subject, it seems] --KkUfzEtIprrm0TMY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/X7TAAoJEJDCuSvBvK1BZLYP/1OEYs8/Maxu8Gevy2L8w+RF hmMWUGvfOtADJlhzzYDAz+hpgodJM2sv6GUbiKfkk9mBPEs1y/oTOwJyY45EQ/ld bYxgRmXwNDxebtUPTsF9YBI/E4GPLMEQlr5FcKGxc2DDitd+M7mlR7UvDwidBcLb q1tqpfUqpEBeybtGN0Mr+AF75uEVfi8oAI75PuBaI0i3QRHuO9kdn+Gie2cP4PHl LCr1WRh+zkvX4ePCAW3G8DnM3Pm/lACzrKJ1iI4O1rlTT/Q0bQe/p5tSFbGDv4H5 PWtmxoKLMY6/e5LYXtN9Qg1PK3H1TEkf7wadR21odC2UVNunOnMMEf1VRb+rXYYK Hw7In5/AjZFF9BllIAIBsZmeLOj7IxuelWLPiBEFqg63Ke13MsMxCDVtLAaXlAai Q4sr8jkGso+zZQrp8T8EY2bWp14jfhruZa04CUy1PfG7iSL3P/RaA+Wq8DpG86Es uZE5gNGmSLVVYFtakWXMBl1S9BO5/clb6bFGSpyIl2b/5FbUr1T9b+koUjXCzw4L NkHsY9LxE5yNnoJYuVvM7Z+WAUAlr3crhYTSvSDpI/3SeNZdDebWWc52cO6gRSNO GYws887DF9Q18NkV685/d0u8/D3V+2fvUzQ+3UBNHVTZgbnqQgcMnkJ5DYvWiag9 cUwaNl+GauD7O11SlDdt =v+pf -----END PGP SIGNATURE----- --KkUfzEtIprrm0TMY-- From owner-freebsd-toolchain@FreeBSD.ORG Tue Jan 22 17:15:58 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02A527B9; Tue, 22 Jan 2013 17:15:58 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id B6AD66F8; Tue, 22 Jan 2013 17:15:57 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1TxhRt-000094-LG; Tue, 22 Jan 2013 20:15:49 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:In-Reply-To:Subject:Cc:To:From; bh=avqOGyNsAxBjpREwfh7RA+Zji/Kjr9KirDLENCSsgx0=; b=scU1cAbN6LbGFYuoj6NotmpGJ2TXUpFLJ3t5qvTfwSZkXy4CiyZ8eM+nEEOnAnF1pZ0QBeJmvmLL7Ff66wVmsN4LhtzmjkYT7tuywCMC7GFp0/M2HmSAuTHABKra8oXunn/NhlnTlWKJ4QLqRJFLAQBUm2/HiEzFO5bval5eF38=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1TxhPU-000Hnu-3N; Tue, 22 Jan 2013 17:13:23 +0000 From: Jan Beich To: bug-followup@freebsd.org Subject: Re: ports/170256: audio/mpg123: SIGNAL 10 (SIGBUS) error In-Reply-To: <201207291139.q6TBdKt2011447@red.freebsd.org> (Julien Cigar's message of "Sun, 29 Jul 2012 11:39:20 GMT") Date: Tue, 22 Jan 2013 12:13:44 -0500 References: <201207291139.q6TBdKt2011447@red.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1TxhPU-000Hnu-3N@internal.tormail.org> Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:15:58 -0000 The bug probably happens with every .mp3 file. Program received signal SIGBUS, Bus error. mpg123_strlen () at dct64_x86_64.S:117 117 movaps (%rcx), %xmm0 (gdb) bt #0 mpg123_strlen () at dct64_x86_64.S:117 #1 0x000000080085e416 in INT123_synth_1to1_stereo_x86_64 (bandPtr_l=0x801c5a700, bandPtr_r=0x801c5b000, fr=0x801c14000) at synth.c:430 #2 0x000000080086b55f in INT123_do_layer3 (fr=0x801c14000) at layer3.c:2028 #3 0x0000000800858c21 in decode_the_frame (fr=0x801c14000) at libmpg123.c:685 #4 0x00000008008595b7 in mpg123_decode_frame (mh=0x801c14000, num=0x624528, audio=0x7fffffffda40, bytes=0x7fffffffda30) at libmpg123.c:824 #5 0x000000000040e445 in play_frame () at mpg123.c:661 #6 0x000000000040ff11 in main (sys_argc=2, sys_argv=0x7fffffffdd28) at mpg123.c:1140 And this is caused by a broken .align check in configure.ac: $ echo '.align 3' | clang -c -o /dev/null -x assembler - $ echo '.align 3' | gcc47 -c -o /dev/null -x assembler - {standard input}: Assembler messages: {standard input}:1: Error: alignment not a power of 2 Exit 1 $ echo '.align 3' | as -o /dev/null {standard input}: Assembler messages: {standard input}:1: Error: alignment not a power of 2 Exit 1 No clue whose bug is this but here's a workaround. --- configure.ac~ +++ configure.ac @@ -838,21 +838,21 @@ dnl ############## Assembler, compiler properties # based on posting from John Dalgliesh on ffmpeg (LGPL) mailing list # find if .align arg is power-of-two or not asmalign_exp="unknown" if test x"$asmalign_exp" = xunknown; then AC_MSG_CHECKING([if .align takes 2-exponent]) asmalign_exp="no" echo '.align 3' > conftest.s - if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then + if $AS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then asmalign_exp="yes" AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) fi rm -f conftest.o conftest.s fi if test x"$asmalign_exp" = xyes; then AC_DEFINE(ASMALIGN_EXP, 1, [ Define if .align takes 3 for alignment of 2^3=8 bytes instead of 8. ]) fi From owner-freebsd-toolchain@FreeBSD.ORG Tue Jan 22 21:11:36 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E2AB0F46; Tue, 22 Jan 2013 21:11:36 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AA87838C; Tue, 22 Jan 2013 21:11:36 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:554:8432:2f53:3a7e] (unknown [IPv6:2001:7b8:3a7:0:554:8432:2f53:3a7e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 067BD5C43; Tue, 22 Jan 2013 22:11:35 +0100 (CET) Message-ID: <50FF0080.5090303@FreeBSD.org> Date: Tue, 22 Jan 2013 22:11:28 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Jan Beich , bug-followup@freebsd.org Subject: Re: ports/170256: audio/mpg123: SIGNAL 10 (SIGBUS) error References: <201207291139.q6TBdKt2011447@red.freebsd.org> <1TxhPU-000Hnu-3N@internal.tormail.org> In-Reply-To: <1TxhPU-000Hnu-3N@internal.tormail.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:11:37 -0000 On 2013-01-22 18:13, Jan Beich wrote: > The bug probably happens with every .mp3 file. ... > And this is caused by a broken .align check in configure.ac: > > $ echo '.align 3' | clang -c -o /dev/null -x assembler - > $ echo '.align 3' | gcc47 -c -o /dev/null -x assembler - > {standard input}: Assembler messages: > {standard input}:1: Error: alignment not a power of 2 > Exit 1 > $ echo '.align 3' | as -o /dev/null > {standard input}: Assembler messages: > {standard input}:1: Error: alignment not a power of 2 > Exit 1 > > No clue whose bug is this but here's a workaround. I'm inclined to say this is a bug in mpg123's configure script, or even simpler, in their code. They shouldn't use .align, but .balign or .p2align, if they want to be sure of the correct alignment. That said, the difference is that gas (depending on arch) errors out when it finds the argument to .align is not a power of 2, while clang accepts such weird alignments. (That is, if you are crazy enough to want to align to 3 bytes, why shouldn't the assembler oblige? :-) > --- configure.ac~ > +++ configure.ac > @@ -838,21 +838,21 @@ > > dnl ############## Assembler, compiler properties > > # based on posting from John Dalgliesh on ffmpeg (LGPL) mailing list > # find if .align arg is power-of-two or not > asmalign_exp="unknown" > if test x"$asmalign_exp" = xunknown; then > AC_MSG_CHECKING([if .align takes 2-exponent]) > asmalign_exp="no" > echo '.align 3' > conftest.s > - if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then > + if $AS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then Well, either this, or just patching src/libmpg123/mangle.h to use the more predictable .balign or .p2align directives. From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 23 08:23:45 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CEFDFD27 for ; Wed, 23 Jan 2013 08:23:45 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 646B8E5 for ; Wed, 23 Jan 2013 08:23:45 +0000 (UTC) Received: from [192.168.1.11] (unknown [217.157.7.221]) by csmtp3.one.com (Postfix) with ESMTPA id 257D22406860 for ; Wed, 23 Jan 2013 08:23:38 +0000 (UTC) From: Erik Cederstrand Content-Type: multipart/mixed; boundary="Apple-Mail=_D26E537B-B33B-436C-9666-7C22FF17F9AC" Subject: [patch] DEBUG_FLAGS cleanup Message-Id: <0CBACA33-7420-4045-AD0C-852983CD64CF@cederstrand.dk> Date: Wed, 23 Jan 2013 09:23:41 +0100 To: "toolchain@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:23:45 -0000 --Apple-Mail=_D26E537B-B33B-436C-9666-7C22FF17F9AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello folks, Attached is a patch to clean up unconditional use of "-g" in Makefiles, = instead respecting the global DEBUG_FLAGS setting. I need this as part of my quest to support deterministic builds. = Currently, debug information contains stuff like timestamps, absolute = paths etc. that make binaries non-deterministic, and Clang lacks the = necessary flags to rectify this. So I'd like DEBUG_FLAGS=3D"" to = actually work everywhere. I'd be thankful for feedback and help committing the changes if it's OK. Thanks, Erik --Apple-Mail=_D26E537B-B33B-436C-9666-7C22FF17F9AC Content-Disposition: attachment; filename=debugflags.txt Content-Type: text/plain; x-unix-mode=0644; name="debugflags.txt" Content-Transfer-Encoding: quoted-printable Index: head/usr.bin/tar/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/usr.bin/tar/Makefile (revision 242791) +++ head/usr.bin/tar/Makefile (working copy) @@ -38,7 +38,6 @@ CFLAGS+=3D -I${LIBARCHIVEDIR}/libarchive_fe SYMLINKS=3D bsdtar ${BINDIR}/tar MLINKS=3D bsdtar.1 tar.1 -DEBUG_FLAGS=3D-g =20 .PHONY: check test clean-test check test: $(PROG) bsdtar.1.gz Index: head/gnu/usr.bin/cc/cc_tools/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/gnu/usr.bin/cc/cc_tools/Makefile (revision 242791) +++ head/gnu/usr.bin/cc/cc_tools/Makefile (working copy) @@ -6,7 +6,7 @@ =20 .include "../Makefile.inc" =20 -CFLAGS+=3D -g +CFLAGS+=3D $(DEBUG_FLAGS) CFLAGS+=3D -DGENERATOR_FILE -DHAVE_CONFIG_H =20 # Override LIBIBERTY set by Makefile.inc, We use our own for Index: head/usr.sbin/bluetooth/bthidd/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/usr.sbin/bluetooth/bthidd/Makefile (revision 242791) +++ head/usr.sbin/bluetooth/bthidd/Makefile (working copy) @@ -8,7 +8,6 @@ session.c =20 CFLAGS+=3D -I${.CURDIR} -DEBUG_FLAGS=3D -g =20 DPADD=3D ${LIBBLUETOOTH} ${LIBUSBHID} LDADD=3D -lbluetooth -lusbhid Index: head/lib/libufs/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/lib/libufs/Makefile (revision 242791) +++ head/lib/libufs/Makefile (working copy) @@ -21,7 +21,6 @@ =20 WARNS?=3D 2 =20 -DEBUG_FLAGS =3D -g CFLAGS+=3D -D_LIBUFS .if defined(LIBUFS_DEBUG) CFLAGS+=3D -D_LIBUFS_DEBUGGING Index: head/crypto/openssl/crypto/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/crypto/openssl/crypto/Makefile (revision 242791) +++ head/crypto/openssl/crypto/Makefile (working copy) @@ -8,7 +8,7 @@ INCLUDE=3D -I. -I$(TOP) -I../include $(ZLIB_INCLUDE) # INCLUDES targets sudbirs! INCLUDES=3D -I.. -I../.. -I../modes -I../asn1 -I../evp = -I../../include $(ZLIB_INCLUDE) -CFLAG=3D -g +CFLAG=3D $(DEBUG_FLAGS) MAKEDEPPROG=3D makedepend MAKEDEPEND=3D $(TOP)/util/domd $(TOP) -MD $(MAKEDEPPROG) MAKEFILE=3D Makefile Index: head/contrib/gcc/Makefile.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/contrib/gcc/Makefile.in (revision 242791) +++ head/contrib/gcc/Makefile.in (working copy) @@ -154,9 +154,9 @@ TCFLAGS =3D CFLAGS =3D @CFLAGS@ LDFLAGS =3D @LDFLAGS@ -STAGE1_CFLAGS =3D -g @stage1_cflags@ +STAGE1_CFLAGS =3D $(DEBUG_FLAGS) @stage1_cflags@ STAGE1_CHECKING_CFLAGS =3D -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -BOOT_CFLAGS =3D -g -O2 +BOOT_CFLAGS =3D $(DEBUG_FLAGS) -O2 =20 # Flags to determine code coverage. When coverage is disabled, this = will # contain the optimization flags, as you normally want code coverage @@ -553,7 +553,7 @@ =20 # Options to use when compiling libgcc2.a. # -LIBGCC2_DEBUG_CFLAGS =3D -g +LIBGCC2_DEBUG_CFLAGS =3D $(DEBUG_FLAGS) LIBGCC2_CFLAGS =3D -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) = $(TARGET_LIBGCC2_CFLAGS) \ $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) \ -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \ Index: head/contrib/gdtoa/makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/contrib/gdtoa/makefile (revision 242791) +++ head/contrib/gdtoa/makefile (working copy) @@ -25,7 +25,7 @@ =20 .SUFFIXES: .c .o CC =3D cc -CFLAGS =3D -g +CFLAGS =3D $(DEBUG_FLAGS) =20 .c.o: $(CC) -c $(CFLAGS) $*.c Index: head/cddl/usr.bin/ctfconvert/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/cddl/usr.bin/ctfconvert/Makefile (revision 242791) +++ head/cddl/usr.bin/ctfconvert/Makefile (working copy) @@ -3,8 +3,6 @@ .PATH: ${.CURDIR}/../../../cddl/contrib/opensolaris/tools/ctf/common .PATH: ${.CURDIR}/../../../cddl/contrib/opensolaris/tools/ctf/cvt =20 -DEBUG_FLAGS=3D -g - PROG=3D ctfconvert SRCS=3D alist.c \ ctf.c \ Index: head/cddl/usr.sbin/lockstat/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/cddl/usr.sbin/lockstat/Makefile (revision 242791) +++ head/cddl/usr.sbin/lockstat/Makefile (working copy) @@ -18,7 +18,7 @@ -I${OPENSOLARIS_SYS_DISTDIR}/compat \ -I${.CURDIR}/../../../sys =20 -CFLAGS+=3D -DNEED_ERRLOC -g +CFLAGS+=3D -DNEED_ERRLOC $(DEBUG_FLAGS) =20 #YFLAGS+=3D -d =20 Index: head/sys/modules/sfxge/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/modules/sfxge/Makefile (revision 242822) +++ head/sys/modules/sfxge/Makefile (working copy) @@ -20,6 +20,6 @@ SRCS+=3D siena_mac.c siena_nic.c siena_nvram.c siena_phy.c SRCS+=3D siena_sram.c siena_vpd.c=20 -DEBUG_FLAGS=3D -g -DDEBUG=3D1 +DEBUG_FLAGS+=3D -DDEBUG=3D1 .include Index: head/sys/modules/cxgb/cxgb/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/modules/cxgb/cxgb/Makefile (revision 242822) +++ head/sys/modules/cxgb/cxgb/Makefile (working copy) @@ -13,7 +13,7 @@ SRCS+=3D opt_inet.h opt_inet6.h opt_zero.h opt_sched.h SRCS+=3D uipc_mvec.c -CFLAGS+=3D -g -DDEFAULT_JUMBO -I${CXGB} +CFLAGS+=3D ${DEBUG_FLAGS} -DDEFAULT_JUMBO -I${CXGB} .if !defined(KERNBUILDDIR) .if ${MK_INET_SUPPORT} !=3D "no" Index: head/sys/modules/cxgb/cxgb_t3fw/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- head/sys/modules/cxgb/cxgb_t3fw/Makefile (revision 242822) +++ head/sys/modules/cxgb/cxgb_t3fw/Makefile (working copy) @@ -1,10 +1,12 @@ # $FreeBSD$ +.include + CXGB =3D ${.CURDIR}/../../../dev/cxgb .PATH: ${CXGB}=20 KMOD=3D cxgb_t3fw SRCS+=3D cxgb_t3fw.c -CFLAGS+=3D -g -I${CXGB} +CFLAGS+=3D ${DEBUG_FLAGS} -I${CXGB} .include = --Apple-Mail=_D26E537B-B33B-436C-9666-7C22FF17F9AC-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 23 10:06:06 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEADC46D for ; Wed, 23 Jan 2013 10:06:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2019975B for ; Wed, 23 Jan 2013 10:06:05 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0NA5wTR050594; Wed, 23 Jan 2013 12:05:58 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0NA5wTR050594 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0NA5w7i050593; Wed, 23 Jan 2013 12:05:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Jan 2013 12:05:58 +0200 From: Konstantin Belousov To: Erik Cederstrand Subject: Re: [patch] DEBUG_FLAGS cleanup Message-ID: <20130123100558.GV2522@kib.kiev.ua> References: <0CBACA33-7420-4045-AD0C-852983CD64CF@cederstrand.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sQTf9N6XI0Qk9QIT" Content-Disposition: inline In-Reply-To: <0CBACA33-7420-4045-AD0C-852983CD64CF@cederstrand.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "toolchain@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 10:06:06 -0000 --sQTf9N6XI0Qk9QIT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2013 at 09:23:41AM +0100, Erik Cederstrand wrote: > Hello folks, >=20 > Attached is a patch to clean up unconditional use of "-g" in Makefiles, i= nstead respecting the global DEBUG_FLAGS setting. >=20 > I need this as part of my quest to support deterministic builds. Currentl= y, debug information contains stuff like timestamps, absolute paths etc. th= at make binaries non-deterministic, and Clang lacks the necessary flags to = rectify this. So I'd like DEBUG_FLAGS=3D"" to actually work everywhere. >=20 > I'd be thankful for feedback and help committing the changes if it's OK. >=20 > Thanks, > Erik >=20 > Index: head/usr.bin/tar/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- head/usr.bin/tar/Makefile (revision 242791) > +++ head/usr.bin/tar/Makefile (working copy) > @@ -38,7 +38,6 @@ > CFLAGS+=3D -I${LIBARCHIVEDIR}/libarchive_fe > SYMLINKS=3D bsdtar ${BINDIR}/tar > MLINKS=3D bsdtar.1 tar.1 > -DEBUG_FLAGS=3D-g > =20 > .PHONY: check test clean-test > check test: $(PROG) bsdtar.1.gz > Index: head/gnu/usr.bin/cc/cc_tools/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- head/gnu/usr.bin/cc/cc_tools/Makefile (revision 242791) > +++ head/gnu/usr.bin/cc/cc_tools/Makefile (working copy) > @@ -6,7 +6,7 @@ > =20 > .include "../Makefile.inc" > =20 > -CFLAGS+=3D -g > +CFLAGS+=3D $(DEBUG_FLAGS) > CFLAGS+=3D -DGENERATOR_FILE -DHAVE_CONFIG_H > =20 > # Override LIBIBERTY set by Makefile.inc, We use our own for This fragment catched my eye, and it is typical for the patch. Why do you need to add DEBUG_FLAGS to the CFLAGS manually ? Wouldn't share/mk magic do this automatically ? If not, I think that it should be considered to fix the remaining cases where DEBUG_FLAGS are not added in the common mk code, instead of sprinkling the additions all over the place ? I think that the cleanup you performed is needed. --sQTf9N6XI0Qk9QIT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/7YGAAoJEJDCuSvBvK1BaX0P/RWdHVCqLQU6k3m+2X7gxzI4 qDEd2cEURrU6/YbIs9QpKmg/QoJ/mJVDnVmez6q8g40R7JCnF24YIdcbk2uHZxY1 EgTummWyTNIsTUkR2WMXlSdTIbFcz1XeT+c/KVQDPuTo44ZrmiVUC+cXdkSPJ+KI 5IAdg7r9/Lr/tf/Oxcnz+YewhbYBPiTn/H6sWuTdhcIhjGJH69S5d83dH7lJeQ+S xw5QOHKzCyJ9JSXnuMoUG+zjytHvOuYg5NONzdRZwBZLEdhQ94bcVZwNJ1Kx1g7o YfHGmGOA8oJOMuESCvrBjjDfxtQpv+/mhr9eRwX0Y2E7kgecKQGtEdAQQ61RiGPQ 4cBdr2O46lrEtiWQu5W1tq/LAmK5Zj1dRC3xTyiQMYcvAH4lNHuUHwHS98RkpCJW tv32Pwix+dswubMECpR0GUV2mEDE597S8S4LOrFuoiuSzGo5JegWifB0IXXGUUey rOxiaQXFM8ebJYaAe7zdEacPaHq3+Fc+bIE5aNRZqgo+iw2g5X15AscBixWe4B/q qKGKFEgdm/74tpyfcrjpP5E81XFOqtOlbH+EhUhOJtw1CBifbmx+Its5lEU373HG bXUq5ueMcM1EmBbIwDMw7cqGfMMJ5QNbETH19d99pr4KMDUkuEPIdzQkJ1G+6wJ3 Bbz+DJKNm32WiFIW/tq0 =9kAn -----END PGP SIGNATURE----- --sQTf9N6XI0Qk9QIT-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 23 10:46:16 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F346BF8 for ; Wed, 23 Jan 2013 10:46:16 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 371B790D for ; Wed, 23 Jan 2013 10:46:16 +0000 (UTC) Received: from [192.168.1.11] (unknown [217.157.7.221]) by csmtp3.one.com (Postfix) with ESMTPA id 60AFD24061B0; Wed, 23 Jan 2013 10:46:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [patch] DEBUG_FLAGS cleanup From: Erik Cederstrand In-Reply-To: <20130123100558.GV2522@kib.kiev.ua> Date: Wed, 23 Jan 2013 11:46:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <13E7EB8C-6815-4969-A3B2-F02A2BC28D5B@cederstrand.dk> References: <0CBACA33-7420-4045-AD0C-852983CD64CF@cederstrand.dk> <20130123100558.GV2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1499) Cc: "toolchain@freebsd.org" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 10:46:16 -0000 Den 23/01/2013 kl. 11.05 skrev Konstantin Belousov = : > On Wed, Jan 23, 2013 at 09:23:41AM +0100, Erik Cederstrand wrote: >> [...] >>=20 >> -CFLAGS+=3D -g >> +CFLAGS+=3D $(DEBUG_FLAGS) >> CFLAGS+=3D -DGENERATOR_FILE -DHAVE_CONFIG_H >>=20 >> # Override LIBIBERTY set by Makefile.inc, We use our own for >=20 > This fragment catched my eye, and it is typical for the patch. > Why do you need to add DEBUG_FLAGS to the CFLAGS manually ? > Wouldn't share/mk magic do this automatically ? Quite possibly. My only reason for this approach was to change as little = as possible. I'll test if I can just remove the line entirely. Thanks, Erik= From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 08:41:17 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF1CBCCF for ; Fri, 25 Jan 2013 08:41:17 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8605D74D for ; Fri, 25 Jan 2013 08:41:17 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0P8fFep077129 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO) for ; Fri, 25 Jan 2013 08:41:16 GMT (envelope-from theraven@FreeBSD.org) From: David Chisnall Content-Type: multipart/signed; boundary="Apple-Mail=_4FB944B6-4BDA-493C-827F-8FDF2A677DA9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Removing default build of gcc Date: Fri, 25 Jan 2013 08:41:11 +0000 Message-Id: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> To: toolchain@FreeBSD.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:41:17 -0000 --Apple-Mail=_4FB944B6-4BDA-493C-827F-8FDF2A677DA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start = disconnecting things from the default build, starting with gcc. I've = been running a gcc-free system for a while, and I think all of the ports = that don't build with clang are now explicitly depending on gcc. Does = anyone have strong opinions on when would be a good time for head on x86 = and x86-64 to default to not building gcc? David --Apple-Mail=_4FB944B6-4BDA-493C-827F-8FDF2A677DA9 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRAkUoAAoJEKx65DEEsqIdG5cQALjUqaqgTrQAvIxDkd4hfHZk 7EOhp2VBrRfn5rvuBNuuQKlIfYVufDtFYwriLZlsjta9lOchgHd8xU9PGK/Y5zlm tXcON2N2Y3uVCny8odsfMyyE4DVfFH6fG/c7/dd7MXgbooAL6aQ0A4EN2Xf5Dtv3 5mS5SkJn5vnhjvVk0Wt3PzOGWQk24JB0MCTE4f80oJL6kNIk69wKb//vIVvdgEzB 0RuJcZ0rEdqdT6soStV6zTK23mJD5sag/jO/hHM20jDXeJcMyCRxNPVP0Gdwfsf2 wWwlu3qbeHDInX8dTepZZB/R6nRSFNu+f4ADagUSGXjdiMoSV4I1j39aSl5754Ru DE7YJ7AnESoyuV4+hO3X8Nebcif3+E/RvRuhY+OELjfYKbuqUzcRlp9Kc1m8fWna LJqrj7kzgjngJEP5VM1VOczxQpfl5KsAYTyWkygKf4zCL5WpqGTTlJRgPYzSZGi1 BnCR6eDAJt1UsTIEdSnbF+DQSr8RrGpeL3E2Yjikk03sSJYTEQuS0mMltgpaoZIf iZPs3jytweQf7uj2pWAXebboTIUaBURCJOBcBczIeTIhg3Ai54AVSTv+zQCGuJYG DnHq/6rznWr3SsJ++U72O+V/NZS3U9JDACQxhV/2uAw6pRQXvLhfSv50OgasmZE4 V6wu4VLFWMRVq6ryf2Hr =BYxg -----END PGP SIGNATURE----- --Apple-Mail=_4FB944B6-4BDA-493C-827F-8FDF2A677DA9-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 08:47:25 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FB1D1CF; Fri, 25 Jan 2013 08:47:25 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6B99B7E1; Fri, 25 Jan 2013 08:47:25 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id CE37B6001; Fri, 25 Jan 2013 02:47:19 -0600 (CST) Date: Fri, 25 Jan 2013 02:47:19 -0600 From: Mark Linimon To: David Chisnall Subject: Re: Removing default build of gcc Message-ID: <20130125084719.GA20770@lonesome.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 08:47:25 -0000 On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: > I think all of the ports that don't build with clang are now explicitly > depending on gcc. Nope. We switched some of the most notorious failures, but hundreds more remain -- mostly leaf ports. Without the ability to run -exp builds, which I do not currently have, this is extremely premature. mcl From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 11:20:57 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A09C1; Fri, 25 Jan 2013 11:20:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [178.238.39.38]) by mx1.freebsd.org (Postfix) with ESMTP id D32AD231; Fri, 25 Jan 2013 11:20:56 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 775031CC5582; Fri, 25 Jan 2013 12:14:11 +0100 (CET) Date: Fri, 25 Jan 2013 12:14:11 +0100 From: Roman Divacky To: Mark Linimon Subject: Re: Removing default build of gcc Message-ID: <20130125111411.GA36209@freebsd.org> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125084719.GA20770@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130125084719.GA20770@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:20:57 -0000 On Fri, Jan 25, 2013 at 02:47:19AM -0600, Mark Linimon wrote: > On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: > > I think all of the ports that don't build with clang are now explicitly > > depending on gcc. > > Nope. We switched some of the most notorious failures, but hundreds > more remain -- mostly leaf ports. > > Without the ability to run -exp builds, which I do not currently have, > this is extremely premature. I also think this is a bit premature, ports is one issue, second one is that other major archs are still with gcc. Developers should be able to fix sources broken on non-clang archs easily. Once arm/mips/ppc are switched (fingers crossed that it's going to be soon) disabling gcc by default should be easier. Roman From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 11:31:29 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 739BAA78 for ; Fri, 25 Jan 2013 11:31:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E2A97282 for ; Fri, 25 Jan 2013 11:31:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0PBVMtU083476 for ; Fri, 25 Jan 2013 13:31:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0PBVMtU083476 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0PBVM0P083475 for toolchain@FreeBSD.org; Fri, 25 Jan 2013 13:31:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jan 2013 13:31:22 +0200 From: Konstantin Belousov To: toolchain@FreeBSD.org Subject: Re: Removing default build of gcc Message-ID: <20130125113122.GN2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDakB1N7OkbC0NTe" Content-Disposition: inline In-Reply-To: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 11:31:29 -0000 --KDakB1N7OkbC0NTe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: > Hi All, >=20 > In 10.0, the plan is not to ship any GPL'd code, so I'd like to start dis= connecting things from the default build, starting with gcc. I've been run= ning a gcc-free system for a while, and I think all of the ports that don't= build with clang are now explicitly depending on gcc. Does anyone have st= rong opinions on when would be a good time for head on x86 and x86-64 to de= fault to not building gcc? To clarify: there is no plans to not ship any GPLed code for 10.x. Instead, there are still plans to ship working 10.x. Please do not consider the personal opinion as the statement of the project policy. --KDakB1N7OkbC0NTe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAm0KAAoJEJDCuSvBvK1Bvk8P/3RQkq8ys5ljpUDnOEUzelTr 312rbkUV4LNpWr/yO6bnnmnbwdvSLZgMB5jvzQwLqBIs4kGiRdxT6sFrQOr7T7se VRVnduI07P491fmyZu1WMWFsxB//vQ7A7OQIOsWWFubmWQMcgQKpuQ2wPTWOJRph vYI0Efnslr/BB9QBHXAregFK+MZ4iwc0BwN6ZJUYJeZWafzstBE+WBYAVB44aspB X5ZEcOQRx/TnTP3kG6XO5UHMs50koI7dW7nxcTj6UZWbuIYABTEOKSJDFxCCPT6k +k2FlQryf5Efljd7E5byb9wYdGe8qm7CjjMSpIvi8aVfQ2VJBgOrSbbtDO7ac9Nh WR82SjR9jNF5SEJ3y5wKcj4Km1K2nmmfix8ZQGu/OirCT/F1taNUS1OG+rUBd2oM IrNW1KIuyR73fCL7MttZMPjYVza8UL5PbophrT2CdZy810bUhgVCNmztInyhMUlE se24HnvO+FEYJOQFrCpBFIzH0QhFTu9F/srZCZqFXMByzbBb+UjjinUGOJQB3J35 8C0tpOjA3IvDtz+hhG9euYhi74aod4iIDHYLWe8mRnYxaeVjBJ5p6y+RBDhLF0vx FvNQ8ZZXdtgUM8fgvGYQlxKDgUAGXVz1101zoa+fiSK5+sDJavx9ojG0P7uoH60o wl1hQRbbOb8KeyXVthlt =1iFJ -----END PGP SIGNATURE----- --KDakB1N7OkbC0NTe-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 13:21:27 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2C5E68D for ; Fri, 25 Jan 2013 13:21:27 +0000 (UTC) (envelope-from theraven@theravensnest.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE1B9AD for ; Fri, 25 Jan 2013 13:21:27 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0PDLJnA078084 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 13:21:20 GMT (envelope-from theraven@theravensnest.org) Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20130125113122.GN2522@kib.kiev.ua> Date: Fri, 25 Jan 2013 13:21:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:21:27 -0000 On 25 Jan 2013, at 11:31, Konstantin Belousov wrote: > To clarify: there is no plans to not ship any GPLed code for 10.x. This is something that has been said on mailing lists, at BSDCan and at = DevSummits in the past, without any objections being raised. If this is = no longer a goal, then that is very sad, because we have currently a = window in which a lot of potential downstream users are looking for a = GPL-free stack and are put off FreeBSD and towards proprietary solutions = because we still require GPL'd code for a working base system. If we = put off this goal for another two years, we are likely to lose a lot of = potential corporate contributors, who will invest in in-house and = proprietary systems instead. > Instead, there are still plans to ship working 10.x. I don't believe that these are contradictory goals and would certainly = not ever prefer a non-working system to a working one. =20 Indeed, in many cases the alternative is a non-working system. For = example, the debugger that we ship doesn't understand DWARF4 generated = by any modern compiler (including gcc or clang). David= From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 14:03:35 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 990B9D8B for ; Fri, 25 Jan 2013 14:03:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C95EFC25 for ; Fri, 25 Jan 2013 14:03:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA02157; Fri, 25 Jan 2013 16:03:14 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510290A1.5010809@FreeBSD.org> Date: Fri, 25 Jan 2013 16:03:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Chisnall Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> In-Reply-To: <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:03:35 -0000 on 25/01/2013 15:21 David Chisnall said the following: > This is something that has been said on mailing lists, at BSDCan and at > DevSummits in the past, without any objections being raised. A simple test - has there been a core decision that no GPL software must be shipped with 10.x? -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 14:10:47 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1BED0EDA; Fri, 25 Jan 2013 14:10:47 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id E00E7CE3; Fri, 25 Jan 2013 14:10:46 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0PEAjmS078235 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 14:10:45 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <510290A1.5010809@FreeBSD.org> Date: Fri, 25 Jan 2013 14:10:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> <510290A1.5010809@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:10:47 -0000 On 25 Jan 2013, at 14:03, Andriy Gapon wrote: > on 25/01/2013 15:21 David Chisnall said the following: >> This is something that has been said on mailing lists, at BSDCan and = at >> DevSummits in the past, without any objections being raised. >=20 > A simple test - has there been a core decision that no GPL software = must be > shipped with 10.x? There can be no such decision until it's all of the bits of GPL'd code = in base have replacements in and testing has happened. That is why it = is a plan, not an accomplished goal. This is why we have the wiki page = tracking the progress of replacements: https://wiki.freebsd.org/GPLinBase David= From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 14:25:44 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8AA5747B; Fri, 25 Jan 2013 14:25:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A0460DF3; Fri, 25 Jan 2013 14:25:43 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA02316; Fri, 25 Jan 2013 16:25:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <510295E5.8060400@FreeBSD.org> Date: Fri, 25 Jan 2013 16:25:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2 MIME-Version: 1.0 To: David Chisnall Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> <510290A1.5010809@FreeBSD.org> <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> In-Reply-To: <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:25:44 -0000 on 25/01/2013 16:10 David Chisnall said the following: > On 25 Jan 2013, at 14:03, Andriy Gapon wrote: > >> on 25/01/2013 15:21 David Chisnall said the following: >>> This is something that has been said on mailing lists, at BSDCan and at >>> DevSummits in the past, without any objections being raised. >> >> A simple test - has there been a core decision that no GPL software must be >> shipped with 10.x? > > There can be no such decision until it's all of the bits of GPL'd code in base > have replacements in and testing has happened. I disagree. Core can make a decision to set a goal. > That is why it is a plan, not > an accomplished goal. Right. The question is - is this a plan set by Core, and so a Project's Plan, or is this a plan that individual project members have set for themselves? As long as there are no conflicts in plans or objections to the plan the distinction is insignificant, but not longer. > This is why we have the wiki page tracking the progress > of replacements: > > https://wiki.freebsd.org/GPLinBase OK. -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 15:45:05 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF634CCC for ; Fri, 25 Jan 2013 15:45:05 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 342B56D0 for ; Fri, 25 Jan 2013 15:45:05 +0000 (UTC) Received: from [192.168.1.11] (unknown [217.157.7.221]) by csmtp2.one.com (Postfix) with ESMTPA id 562FF303CC6F; Fri, 25 Jan 2013 15:44:58 +0000 (UTC) From: Erik Cederstrand Content-Type: multipart/mixed; boundary="Apple-Mail=_4613EB0F-32BC-4198-BFCC-CD9D235BAAC5" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: [patch] crunchide breaks object files when using mclinker to do base system linking Date: Fri, 25 Jan 2013 16:44:59 +0100 References: To: "toolchain@freebsd.org" X-Mailer: Apple Mail (2.1499) Cc: pete chou X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:45:05 -0000 --Apple-Mail=_4613EB0F-32BC-4198-BFCC-CD9D235BAAC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello list, On behalf of Pete Chou, I would like to ask for review, testing and = hopefully commit help of this revised patch for crunchgen and crunchide = which allows mclinker (http://code.google.com/p/mclinker/) to link the = base system. In short, this patch is needed because crunchide is being = overly strict about the section layout of an object file. Thanks, Erik --Apple-Mail=_4613EB0F-32BC-4198-BFCC-CD9D235BAAC5 Content-Disposition: attachment; filename=patch-6.txt Content-Type: text/plain; x-unix-mode=0644; name="patch-6.txt" Content-Transfer-Encoding: 7bit Index: exec_elf32.c =================================================================== --- exec_elf32.c (revision 244199) +++ exec_elf32.c (working copy) @@ -45,6 +45,7 @@ #include #include +#include #include #include #include @@ -82,11 +83,9 @@ #define xe32toh(x) ((data == ELFDATA2MSB) ? be32toh(x) : le32toh(x)) #define htoxe32(x) ((data == ELFDATA2MSB) ? htobe32(x) : htole32(x)) -struct listelem { - struct listelem *next; - void *mem; - off_t file; - size_t size; +struct shlayout { + Elf_Shdr *shdr; + void *bufp; }; static ssize_t @@ -235,17 +234,20 @@ ELFNAMEEND(hide)(int fd, const char *fn) { Elf_Ehdr ehdr; - Elf_Shdr *shdrp = NULL, *symtabshdr, *strtabshdr; + struct shlayout *layoutp = NULL; + Elf_Shdr *shdrp = NULL, *symtabshdr, *strtabshdr, *shstrtabshdr; + Elf_Shdr shdrshdr; Elf_Sym *symtabp = NULL; - char *strtabp = NULL; - Elf_Size nsyms, ewi; + char *shstrtabp = NULL, *strtabp = NULL; + Elf_Size nsyms, ewi; + Elf_Off off; ssize_t shdrsize; - int rv, i, weird; - size_t nstrtab_size, nstrtab_nextoff, fn_size; + int rv, i, weird, l, m, r, strtabidx; + size_t nstrtab_size, nstrtab_nextoff, fn_size, size; char *nstrtabp = NULL; unsigned char data; - Elf_Off maxoff, stroff; const char *weirdreason = NULL; + void *buf; rv = 0; if (xreadatoff(fd, &ehdr, 0, sizeof ehdr, fn) != sizeof ehdr) @@ -260,63 +262,124 @@ shdrsize) goto bad; - symtabshdr = strtabshdr = NULL; + symtabshdr = strtabshdr = shstrtabshdr = NULL; weird = 0; - maxoff = stroff = 0; for (i = 0; i < xe16toh(ehdr.e_shnum); i++) { - if (xewtoh(shdrp[i].sh_offset) > maxoff) - maxoff = xewtoh(shdrp[i].sh_offset); switch (xe32toh(shdrp[i].sh_type)) { case SHT_SYMTAB: - if (symtabshdr != NULL) + if (symtabshdr != NULL) { weird = 1; + weirdreason = "multiple symbol tables"; + } symtabshdr = &shdrp[i]; strtabshdr = &shdrp[xe32toh(shdrp[i].sh_link)]; - - /* Check whether the string table is the last section */ - stroff = xewtoh(shdrp[xe32toh(shdrp[i].sh_link)].sh_offset); - if (!weird && xe32toh(shdrp[i].sh_link) != (xe16toh(ehdr.e_shnum) - 1)) { - weird = 1; - weirdreason = "string table not last section"; - } break; + case SHT_STRTAB: + if (i == xe16toh(ehdr.e_shstrndx)) + shstrtabshdr = &shdrp[i]; + break; } } - if (! weirdreason) - weirdreason = "unsupported"; if (symtabshdr == NULL) goto out; - if (strtabshdr == NULL) + if (strtabshdr == NULL) { weird = 1; - if (!weird && stroff != maxoff) { + weirdreason = "string table does not exist"; + } + if (shstrtabshdr == NULL) { weird = 1; - weirdreason = "string table section not last in file"; - } + weirdreason = "section header string table does not exist"; + } + if (weirdreason == NULL) + weirdreason = "unsupported"; if (weird) { fprintf(stderr, "%s: weird executable (%s)\n", fn, weirdreason); goto bad; } /* + * sort section layout table by offset + */ + layoutp = xmalloc(sizeof(struct shlayout) * (xe16toh(ehdr.e_shnum) + 1), + fn, "layout table"); + if (layoutp == NULL) + goto bad; + + /* add a pseudo entry to represent the section header table */ + shdrshdr.sh_offset = ehdr.e_shoff; + shdrshdr.sh_size = htoxew(shdrsize); + shdrshdr.sh_addralign = htoxew(ELFSIZE / 8); + layoutp[xe16toh(ehdr.e_shnum)].shdr = &shdrshdr; + + /* insert and sort normal section headers */ + for (i = xe16toh(ehdr.e_shnum) - 1; i >= 0; i--) { + l = i + 1; + r = xe16toh(ehdr.e_shnum); + while (l <= r) { + m = ( l + r) / 2; + if (xewtoh(shdrp[i].sh_offset) > + xewtoh(layoutp[m].shdr->sh_offset)) + l = m + 1; + else + r = m - 1; + } + + if (r != i) { + memmove(&layoutp[i], &layoutp[i + 1], + sizeof(struct shlayout) * (r - i)); + } + + layoutp[r].shdr = &shdrp[i]; + layoutp[r].bufp = NULL; + } + + /* * load up everything we need */ - /* symbol table */ - if ((symtabp = xmalloc(xewtoh(symtabshdr->sh_size), fn, "symbol table")) - == NULL) + /* load section string table for debug use */ + if ((shstrtabp = xmalloc(xewtoh(shstrtabshdr->sh_size), fn, + "section string table")) == NULL) goto bad; - if (xreadatoff(fd, symtabp, xewtoh(symtabshdr->sh_offset), - xewtoh(symtabshdr->sh_size), fn) != xewtoh(symtabshdr->sh_size)) + if (xreadatoff(fd, shstrtabp, xewtoh(shstrtabshdr->sh_offset), + xewtoh(shstrtabshdr->sh_size), fn) != xewtoh(shstrtabshdr->sh_size)) goto bad; - /* string table */ - if ((strtabp = xmalloc(xewtoh(strtabshdr->sh_size), fn, "string table")) - == NULL) - goto bad; - if (xreadatoff(fd, strtabp, xewtoh(strtabshdr->sh_offset), - xewtoh(strtabshdr->sh_size), fn) != xewtoh(strtabshdr->sh_size)) - goto bad; + /* we need symtab, strtab, and everything behind strtab */ + strtabidx = INT_MAX; + for (i = 0; i < xe16toh(ehdr.e_shnum) + 1; i++) { + if (layoutp[i].shdr == &shdrshdr) { + /* not load section header again */ + layoutp[i].bufp = shdrp; + continue; + } + if (layoutp[i].shdr == shstrtabshdr) { + /* not load section string table again */ + layoutp[i].bufp = shstrtabp; + continue; + } + if (layoutp[i].shdr == strtabshdr) + strtabidx = i; + if (layoutp[i].shdr == symtabshdr || i >= strtabidx) { + off = xewtoh(layoutp[i].shdr->sh_offset); + size = xewtoh(layoutp[i].shdr->sh_size); + layoutp[i].bufp = xmalloc(size, fn, + shstrtabp + xewtoh(layoutp[i].shdr->sh_name)); + if (layoutp[i].bufp == NULL) + goto bad; + if (xreadatoff(fd, layoutp[i].bufp, off, size, fn) != + size) + goto bad; + + /* set symbol table and string table */ + if (layoutp[i].shdr == symtabshdr) + symtabp = layoutp[i].bufp; + else if (layoutp[i].shdr == strtabshdr) + strtabp = layoutp[i].bufp; + } + } + nstrtab_size = 256; nstrtabp = xmalloc(nstrtab_size, fn, "new string table"); if (nstrtabp == NULL) @@ -365,26 +428,63 @@ strtabshdr->sh_size = htoxew(nstrtab_nextoff); /* - * write new tables to the file + * update section header table in ascending order of offset */ - if (xwriteatoff(fd, shdrp, xewtoh(ehdr.e_shoff), shdrsize, fn) != - shdrsize) - goto bad; - if (xwriteatoff(fd, symtabp, xewtoh(symtabshdr->sh_offset), - xewtoh(symtabshdr->sh_size), fn) != xewtoh(symtabshdr->sh_size)) - goto bad; - /* write new symbol table strings */ - if ((size_t)xwriteatoff(fd, nstrtabp, xewtoh(strtabshdr->sh_offset), - xewtoh(strtabshdr->sh_size), fn) != xewtoh(strtabshdr->sh_size)) - goto bad; + for (i = strtabidx + 1; i < xe16toh(ehdr.e_shnum) + 1; i++) { + Elf_Off off, align; + off = xewtoh(layoutp[i - 1].shdr->sh_offset) + + xewtoh(layoutp[i - 1].shdr->sh_size); + align = xewtoh(layoutp[i].shdr->sh_addralign); + off = (off + (align - 1)) & ~(align - 1); + layoutp[i].shdr->sh_offset = htoxew(off); + } + /* + * write data to the file in descending order of offset + */ + for (i = xe16toh(ehdr.e_shnum); i >= 0; i--) { + if (layoutp[i].shdr == strtabshdr) { + /* new string table */ + buf = nstrtabp; + } else + buf = layoutp[i].bufp; + + if (layoutp[i].shdr == &shdrshdr || + layoutp[i].shdr == symtabshdr || i >= strtabidx) { + if (buf == NULL) + goto bad; + + /* + * update the offset of section header table in elf + * header if needed. + */ + if (layoutp[i].shdr == &shdrshdr && + ehdr.e_shoff != shdrshdr.sh_offset) { + ehdr.e_shoff = shdrshdr.sh_offset; + off = (ELFSIZE == 32) ? 32 : 44; + size = sizeof(Elf_Off); + if (xwriteatoff(fd, &ehdr.e_shoff, off, size, + fn) != size) + goto bad; + } + + off = xewtoh(layoutp[i].shdr->sh_offset); + size = xewtoh(layoutp[i].shdr->sh_size); + if (xwriteatoff(fd, buf, off, size, fn) != size) + goto bad; + } + } + out: - if (shdrp != NULL) - free(shdrp); - if (symtabp != NULL) - free(symtabp); - if (strtabp != NULL) - free(strtabp); + if (layoutp != NULL) { + for (i = 0; i < xe16toh(ehdr.e_shnum) + 1; i++) { + if (layoutp[i].bufp != NULL) + free(layoutp[i].bufp); + } + free(layoutp); + } + if (nstrtabp != NULL) + free(nstrtabp); return (rv); bad: --Apple-Mail=_4613EB0F-32BC-4198-BFCC-CD9D235BAAC5-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 19:31:51 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E68ACC4 for ; Fri, 25 Jan 2013 19:31:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f173.google.com (mail-gg0-f173.google.com [209.85.161.173]) by mx1.freebsd.org (Postfix) with ESMTP id A515F2E1 for ; Fri, 25 Jan 2013 19:31:50 +0000 (UTC) Received: by mail-gg0-f173.google.com with SMTP id b6so116435ggm.4 for ; Fri, 25 Jan 2013 11:31:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=b/W2CJIhYccPKgsJLwMRmVEd2w3gzbrcKE3rHMdJ5TI=; b=oZrRNvGl+8p/yxyM40BBFLfXKw6ZBtb7kgce9+T5FxfrpOYS/HFn7MVoCIzHT8nhwD 2kp4sQq6421GDXdaRlkWImOhMA8Tyc0DrRDT8t0v8CUBMHqojQAC/F1bU9s3fttgZR3K zcI5U8lQD9uSwSCsPbXCQ5kQ2l7xEY2LOidRkItSLuDlLJ3PSz0G6VaN7uRsPYyxe7Cu WtEnOmJ/aH5yRhpBRGPh4psGCnd4vh1gbly93xd9+sGHXyaA8XRPX3INbFgzBZYgQiXa 9PIlj6Suinawd8tk+kDtU8GmokKZ/SBmqN1N1Aec/FatXuCyWEOGrhRDP0JNJKy3m9Ed c8tw== X-Received: by 10.100.209.15 with SMTP id h15mr2046588ang.30.1359142304180; Fri, 25 Jan 2013 11:31:44 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id z1sm1665504anj.2.2013.01.25.11.31.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 11:31:42 -0800 (PST) Sender: Warner Losh Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130125113122.GN2522@kib.kiev.ua> Date: Fri, 25 Jan 2013 12:31:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmrgsyacoxJaEvf4lf1UW5GrnYuH+3GhmRWbgoPE7qzwP0DeQQaBVFfHirBWyhmeexvuxtY Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:31:51 -0000 On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: > On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: >> Hi All, >>=20 >> In 10.0, the plan is not to ship any GPL'd code, so I'd like to start = disconnecting things from the default build, starting with gcc. I've = been running a gcc-free system for a while, and I think all of the ports = that don't build with clang are now explicitly depending on gcc. Does = anyone have strong opinions on when would be a good time for head on x86 = and x86-64 to default to not building gcc? >=20 > To clarify: there is no plans to not ship any GPLed code for 10.x. > Instead, there are still plans to ship working 10.x. >=20 > Please do not consider the personal opinion as the statement of the = project > policy. The goal is to try not to ship GPL'd code in 10. The goal is not to ship = 10 without GPL'd code if that results in a broken system. The goal also = as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 = systems may use GPL code as a fallback if the non-gpl'd code doesn't = work on those platforms. That is to say, it is a goal, not an absolute requirement. Warner From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 19:35:55 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E344F3D for ; Fri, 25 Jan 2013 19:35:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f180.google.com (mail-ye0-f180.google.com [209.85.213.180]) by mx1.freebsd.org (Postfix) with ESMTP id 6442431F for ; Fri, 25 Jan 2013 19:35:55 +0000 (UTC) Received: by mail-ye0-f180.google.com with SMTP id r14so118768yen.39 for ; Fri, 25 Jan 2013 11:35:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=ZY8U23oak451Rn1iEh1RNwcmzRHMeNNkv41yynWWrW8=; b=OoGjPGWxkZ2Vwf8B85CP4unCSgwAiBpwyGKtP/WZ4vE4spXKDCjKD1Ubgn2zDog8mk ImWnbxiwXFJwaBH/uztXgIUBIlohE2Wg3up8oKM58tI+LTReRNYSnCgYbiBhCvAZHTrr 4Q71if8l3VX/uqAO/jgdhY3Mg+4dCtSdlIat/WjviHiK8sYSK/ZeD2xOn1uQkF5p+zkn WxTXZfiNpuy/SgU0P+LaVWu5fCID8f34TZ5MfoIn6P03B15sFOD9AzYPzFTTx7hz3dYx 9PjrhQYFeFmv3Ts00w22SZslsJkHR2D7FoCNjtyUrHUL44lHHlsu5AAhTyabGqPrkUCB vETQ== X-Received: by 10.236.149.146 with SMTP id x18mr7296584yhj.29.1359142548861; Fri, 25 Jan 2013 11:35:48 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id j8sm1664205ank.21.2013.01.25.11.35.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 11:35:47 -0800 (PST) Sender: Warner Losh Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <510295E5.8060400@FreeBSD.org> Date: Fri, 25 Jan 2013 12:35:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B3FB147-6A38-4E2A-A5CA-F5EDEE1C0B5E@bsdimp.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> <510290A1.5010809@FreeBSD.org> <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> <510295E5.8060400@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmEKeCt3ew09AccgADGuy7uxVjm+/x4S4LnuW69nXtDUSuH/rggnWXY8tTQ8+NPio1jyyhI Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:35:55 -0000 On Jan 25, 2013, at 7:25 AM, Andriy Gapon wrote: > on 25/01/2013 16:10 David Chisnall said the following: >> On 25 Jan 2013, at 14:03, Andriy Gapon wrote: >>=20 >>> on 25/01/2013 15:21 David Chisnall said the following: >>>> This is something that has been said on mailing lists, at BSDCan = and at=20 >>>> DevSummits in the past, without any objections being raised. >>>=20 >>> A simple test - has there been a core decision that no GPL software = must be=20 >>> shipped with 10.x? >>=20 >> There can be no such decision until it's all of the bits of GPL'd = code in base >> have replacements in and testing has happened. >=20 > I disagree. Core can make a decision to set a goal. This has been talked about in a vague way for years. The various pages = around to document the process. Core has said that it supports the goal, = but hasn't made it a Direction Of The Project because core has not in = the past decade made any such pronouncements. >> That is why it is a plan, not >> an accomplished goal. >=20 > Right. The question is - is this a plan set by Core, and so a = Project's Plan, or > is this a plan that individual project members have set for = themselves? > As long as there are no conflicts in plans or objections to the plan = the > distinction is insignificant, but not longer. It is a project plan, based on the consensus of those working towards = this goal. >> This is why we have the wiki page tracking the progress >> of replacements: >>=20 >> https://wiki.freebsd.org/GPLinBase >=20 > OK. The DTC2 stuff isn't strictly required to have a GPL free system. The = DTC2 stuff is only needed if you want to use non GPL'd tools to compile = .dts files. Since these are typically in the firmware only, that makes = the dtc compiler an optional tool. There's other issues with that page = too.... Warner= From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 19:59:51 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BFD876E for ; Fri, 25 Jan 2013 19:59:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D31B6688 for ; Fri, 25 Jan 2013 19:59:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0PJxfeV041147; Fri, 25 Jan 2013 21:59:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0PJxfeV041147 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0PJxfR1041146; Fri, 25 Jan 2013 21:59:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jan 2013 21:59:41 +0200 From: Konstantin Belousov To: Warner Losh Subject: Re: Removing default build of gcc Message-ID: <20130125195941.GW2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hsoAP4Wa+/L9NF1J" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:59:51 -0000 --hsoAP4Wa+/L9NF1J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: >=20 > On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: >=20 > > On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: > >> Hi All, > >>=20 > >> In 10.0, the plan is not to ship any GPL'd code, so I'd like to start = disconnecting things from the default build, starting with gcc. I've been = running a gcc-free system for a while, and I think all of the ports that do= n't build with clang are now explicitly depending on gcc. Does anyone have= strong opinions on when would be a good time for head on x86 and x86-64 to= default to not building gcc? > >=20 > > To clarify: there is no plans to not ship any GPLed code for 10.x. > > Instead, there are still plans to ship working 10.x. > >=20 > > Please do not consider the personal opinion as the statement of the pro= ject > > policy. >=20 > The goal is to try not to ship GPL'd code in 10. The goal is not to ship = 10 without GPL'd code if that results in a broken system. The goal also as = articulated at different forum, was for Tier 1 systems. Tier 2 and 3 syste= ms may use GPL code as a fallback if the non-gpl'd code doesn't work on tho= se platforms. >=20 > That is to say, it is a goal, not an absolute requirement. All you said is reasonable and quite coincides with what I thought. Unfortunately, it has very tangential relations to what is proposed to do and to the political agenda declared in the message started the thread. I am really tired of the constant struggle against the consumation of the FreeBSD as the test-bed for the pre-alpha quality software. E.g., are we fine with broken C++ runtime in 9 ? --hsoAP4Wa+/L9NF1J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAuQsAAoJEJDCuSvBvK1ByWMP/35NGauTQDjybB/wTLL0t1HK 20B1Ioi1/6sQiemRtrTN0bL5egKN1zOzKlfq43vMxjIwwM2fTGfo9XZ8N+rZo4VL tNPIcOfZH0qXnGLbDAI19IqNsd5VRvHwJc6i0+ipnRCGeFvUtXeQxXlp51fzlSTJ B1OJjoe/vokz6O6BgY33lW0bJbPGfqoIgqUdAmJkouBLQeE2MeVEKMr9ALCSQdS0 GtcQ+UcfQAXBsqHQqZ9qwKIyDjQq2diYIB7GSxpx0J7e/6Ku21FLdBFY4yfhEsCt vm/mX++VqL5cJqEshKkMNWb0J7CeEvmmt7XAxuCfmsMzpaod6dgobr3fl/AR29Jo fpeoV1mIx8qeIQcK2OsvZgKiE643ukRH5WahXJJZgAu3z9n/8lf4XstmBSmSTeCD hvrxKGIRwvWn3n5O0aecibzcPKBPmQaHqIWqBXS19G0vIwDJ1GwkgalafV1LxaiV HcvHYbAwtQ1OUNr6YNekuPE6L3wzFb41MknSIR3SafpPXqc4nLr4EBDdPe+9aKS8 t5retCsm5iaBvpxim9h3ryt4sbEK2l5VsHzuUOsIZTYfBgF0/vDT2BeAo9kia5wx +DQHDlabmB5aD6KYTQIZ871N5nkU1GgRnp5YFLsZoxx3e7rhnb4oqlwR6iMykHLY 5xUVH9z6dTwahF3KEU1j =7+xL -----END PGP SIGNATURE----- --hsoAP4Wa+/L9NF1J-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 20:07:00 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D655C927 for ; Fri, 25 Jan 2013 20:07:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f181.google.com (mail-gg0-f181.google.com [209.85.161.181]) by mx1.freebsd.org (Postfix) with ESMTP id 86FA06D4 for ; Fri, 25 Jan 2013 20:07:00 +0000 (UTC) Received: by mail-gg0-f181.google.com with SMTP id e5so123064ggh.40 for ; Fri, 25 Jan 2013 12:06:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=WT9vd4K3wT8bWyqdalwyHQRn1PkLFeiEjQj6dVfEb4Q=; b=nI3UVHyoq2ILfdFwPEvUboM+GhW6razvm/6wIUkfzOMPwZBwSl1rriIUEJn/+KE7VO uzRxHZqy+qPuIQqlzgBvu021AVP536NSCEOE637WceSver77aE31WaybuDCwAXlhT+Tc 7AXitV9KA8kFl5MwGFoixlX++qbdIXt8qsFauOk05oBUutWlLpmnb4jtWtbeHyp82IuE 7IZ9MwfISRNFX3jgACSE5RCvSeOerCYgGS04D81hi9XMDqrzyFNJtCybc7dG/2kPuqKm 0hq9zyYeJDB2QHksUVNkbsJFV7sLfm3ieaTVgZN1744vh7AhNP5PenTY8PX4LXE+wDeG D2qQ== X-Received: by 10.101.180.7 with SMTP id h7mr2107245anp.15.1359142969557; Fri, 25 Jan 2013 11:42:49 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id r17sm1690856ani.8.2013.01.25.11.42.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 11:42:47 -0800 (PST) Sender: Warner Losh Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> Date: Fri, 25 Jan 2013 12:42:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51FD0757-D1C6-4B35-A944-72DEACDB6C67@bsdimp.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnzrbsnz/Ay9zvQtawhOBP3jhYSA/f9FFRfyF5TkPExT5gs78dY2f1NI8vkTFEX4mgoD7hN Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:07:00 -0000 On Jan 25, 2013, at 1:41 AM, David Chisnall wrote: > Hi All, >=20 > In 10.0, the plan is not to ship any GPL'd code, so I'd like to start = disconnecting things from the default build, starting with gcc. I've = been running a gcc-free system for a while, and I think all of the ports = that don't build with clang are now explicitly depending on gcc. Does = anyone have strong opinions on when would be a good time for head on x86 = and x86-64 to default to not building gcc? clang is producing good code on arm and mips is it? Also, if and when you do the switch, make sure you do it right. dtc is = one example of something we don't build sometimes based on the target. = Follow that example, or you'll break things :) Warner From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 20:36:27 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAA4616C for ; Fri, 25 Jan 2013 20:36:27 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm38-vm7.bullet.mail.bf1.yahoo.com (nm38-vm7.bullet.mail.bf1.yahoo.com [72.30.239.23]) by mx1.freebsd.org (Postfix) with ESMTP id 5EE887F0 for ; Fri, 25 Jan 2013 20:36:26 +0000 (UTC) Received: from [98.139.215.142] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2013 20:36:18 -0000 Received: from [98.139.213.12] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2013 20:36:18 -0000 Received: from [127.0.0.1] by smtp112.mail.bf1.yahoo.com with NNFMP; 25 Jan 2013 20:36:18 -0000 X-Yahoo-Newman-Id: 424270.17547.bm@smtp112.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tTV46_wVM1m9q7twmNGFtG59VoeJr9kW_tGmqCcls6tN4yM klATgRV9RxN5MjjfqhCq1h4ffRKpf_EWZg2yI9gj2cBH8HphRFV_nVpPhgvK k2j1aUrzkDy2muSc8ZFpdCMungEdPhn2KQfcSASEaaRntOzezSj2jF1YJNpG x5dBD1k6RaEroWqm5xGK9zRUKtZEZARWfhexSVvvBUhac9.2CakrElNTsvhI AsWU6bsvtys6ZeYM1HRsbDfCdPSTHgyoZdAm0d5MmuPzOCA_EORqaYoPW4rZ YkhdYwZ9gBdIHg8ueH0LBj.zdFMdT27DXlXwhTZ0F.eJ9rJAGLTSFXT73Kho fjZj_lD6rWUwtclzgaLiVMmJv2R1VmYY1XN9NfpUFuICPClN0J7sXt1iXhLd 2Mksl2i79Y4iaccL934N6XmiyHgdKm287Psv9TXLFxDTO_UfDCe3gvJO.ERN MHFQKsNuuHVw- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp112.mail.bf1.yahoo.com with SMTP; 25 Jan 2013 12:36:17 -0800 PST Message-ID: <5102ECBF.4060500@FreeBSD.org> Date: Fri, 25 Jan 2013 15:36:15 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> In-Reply-To: <20130125195941.GW2522@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:36:27 -0000 On 01/25/2013 14:59, Konstantin Belousov wrote: > On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: >> On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: >> >>> On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: >>>> Hi All, >>>> >>>> In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a gcc-free system for a while, and I think all of the ports that don't build with clang are now explicitly depending on gcc. Does anyone have strong opinions on when would be a good time for head on x86 and x86-64 to default to not building gcc? >>> To clarify: there is no plans to not ship any GPLed code for 10.x. >>> Instead, there are still plans to ship working 10.x. >>> >>> Please do not consider the personal opinion as the statement of the project >>> policy. >> The goal is to try not to ship GPL'd code in 10. The goal is not to ship 10 without GPL'd code if that results in a broken system. The goal also as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 systems may use GPL code as a fallback if the non-gpl'd code doesn't work on those platforms. >> >> That is to say, it is a goal, not an absolute requirement. > All you said is reasonable and quite coincides with what I thought. > > Unfortunately, it has very tangential relations to what is proposed to > do and to the political agenda declared in the message started the thread. I don't care much about gcc in current. It doesn't seem like the right time to kill it but it is a dead end and we should be using the pre pkg'ed version instead (I know, easier said than done, but the Debian guys did it). Either way, there is no hurry but it is a desirable goal. > I am really tired of the constant struggle against the consumation of > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > are we fine with broken C++ runtime in 9 ? The libstdc++ issue is really REALLY worrying. I would prefer if the hack to attempt using libstdc++ as a filter library were reverted altogether in 9.x. I had a lots of stress with that issue as some people pointed at my libstdc++ updates as possible root cause. I felt some natural relief when the real cause was found but I certainly wonder why the change was made in 9.x though since it's clear that codebase will not be migrated to libc++. Pedro. From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 20:44:38 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 983FF69B; Fri, 25 Jan 2013 20:44:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EAEC2849; Fri, 25 Jan 2013 20:44:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0PKiUxl045899; Fri, 25 Jan 2013 22:44:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0PKiUxl045899 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0PKiUvf045898; Fri, 25 Jan 2013 22:44:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jan 2013 22:44:30 +0200 From: Konstantin Belousov To: Pedro Giffuni Subject: Re: Removing default build of gcc Message-ID: <20130125204430.GX2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PeEtTtIyPIoxp38l" Content-Disposition: inline In-Reply-To: <5102ECBF.4060500@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:44:38 -0000 --PeEtTtIyPIoxp38l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > On 01/25/2013 14:59, Konstantin Belousov wrote: > > On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: > >> On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: > >> > >>> On Fri, Jan 25, 2013 at 08:41:11AM +0000, David Chisnall wrote: > >>>> Hi All, > >>>> > >>>> In 10.0, the plan is not to ship any GPL'd code, so I'd like to star= t disconnecting things from the default build, starting with gcc. I've bee= n running a gcc-free system for a while, and I think all of the ports that = don't build with clang are now explicitly depending on gcc. Does anyone ha= ve strong opinions on when would be a good time for head on x86 and x86-64 = to default to not building gcc? > >>> To clarify: there is no plans to not ship any GPLed code for 10.x. > >>> Instead, there are still plans to ship working 10.x. > >>> > >>> Please do not consider the personal opinion as the statement of the p= roject > >>> policy. > >> The goal is to try not to ship GPL'd code in 10. The goal is not to sh= ip 10 without GPL'd code if that results in a broken system. The goal also = as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 sy= stems may use GPL code as a fallback if the non-gpl'd code doesn't work on = those platforms. > >> > >> That is to say, it is a goal, not an absolute requirement. > > All you said is reasonable and quite coincides with what I thought. > > > > Unfortunately, it has very tangential relations to what is proposed to > > do and to the political agenda declared in the message started the thre= ad. >=20 > I don't care much about gcc in current. It doesn't seem like the right ti= me > to kill it but it is a dead end and we should be using the pre pkg'ed=20 > version > instead (I know, easier said than done, but the Debian guys did it). >=20 > Either way, there is no hurry but it is a desirable goal. >=20 > > I am really tired of the constant struggle against the consumation of > > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > > are we fine with broken C++ runtime in 9 ? >=20 > The libstdc++ issue is really REALLY worrying. > I would prefer if the hack to attempt using libstdc++ as a filter > library were reverted altogether in 9.x. >=20 > I had a lots of stress with that issue as some people pointed at > my libstdc++ updates as possible root cause. I felt some natural > relief when the real cause was found but I certainly wonder why > the change was made in 9.x though since it's clear that codebase > will not be migrated to libc++. You were finger-pointed due to the rule 'blame the last committer =66rom the VCS log'. Even less so, you were asked about it because you probably knew most about possible cause. I am not worried about the bug itself, which needs a proper identification and fixing. I am indeed wery disappointed regarding the attitude of the person who introduced the bug. Reverting the split may be the best action in my opinion. Both in head and stable. --PeEtTtIyPIoxp38l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRAu6uAAoJEJDCuSvBvK1BwdwP/1bPxo3OZh9O53cBY8yA4uFq OY2xhkaYHZUhpMDRbEN87WJA2JgZgVJtSoibIVib2AgMmMLdI3b5ZXYrl1NtQD9T ig7XBnr4ZzF+ItlgpRN5D9qc17SEZa+UTiYCUKNdrsGgBgReen53jFr0cJf5ACpw dB13MkFOS34jPRGumZh+WcxxGouifE1W6xPIEwLrLc40Q30kJC7YH/44FY7pYbGc WH04Uj4mzkLpXfbW2xO/iDIcj058IRw/PVl5IZOdW0+SCT11XUcx5tf9nNDciwL1 l2tnwNQ+EX8I9KBKSGlCt7pQTUNxg1w1ykW8IqrU3/qcfzkY1J38eLXh5IzXAA1f r38Uhsqkr+Svb0DyPDC1oYNiWLS99sRnWMBeX6EWft6kd03iZYmOitqPADtZfxih TnrU3e4cNabuQVW3JoKWH+eUysOWF95Y6WaGswNdniYcLqzaSrUJwZ/DpjimGzv5 0WMPiScHZtoy4r99xj25ZGwnNaJT3Rm1NXslORQmckrzuQSRjzhYdyF4F9Z8CrRp kuJrL+uTOSTJNH+ZvOsA2IdfPRbV9Hjiapxzagd0/oFoPefINZOYKmho4nb1BNly 4AklpzQWQYxaierKGdc7MqWR8IAgWtqJadvyr/G5OxA6t592zBnx5fdxlLU968Ex PSA23nZ3l6lDOLmU2/IR =uq+e -----END PGP SIGNATURE----- --PeEtTtIyPIoxp38l-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 20:54:40 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61199AC2 for ; Fri, 25 Jan 2013 20:54:40 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm26-vm6.bullet.mail.gq1.yahoo.com (nm26-vm6.bullet.mail.gq1.yahoo.com [98.136.216.133]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9B38D3 for ; Fri, 25 Jan 2013 20:54:39 +0000 (UTC) Received: from [98.137.12.63] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 20:54:34 -0000 Received: from [98.136.185.42] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 20:54:34 -0000 Received: from [127.0.0.1] by smtp103.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 20:54:34 -0000 X-Yahoo-Newman-Id: 164219.74651.bm@smtp103.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WdbY3tcVM1lCLlvgA0yd7ONpom_4RGBrlp1dnxlaNdM74s5 eZevlG6ua2aaP832eN0iiTsYc1J8dX2pkwgj2LPLWDj1mu6TDcvgqiqTn8rV 0P_XG04xbDV9QkszxQBddgbCGDWkjZtFQxhQIzxD7LleNAkaIxxV1dbWLGYi T8E_oIGtwgl17qTd09yVuJderatQkXtCz01nARUYuDSDaSuWFjCxBIN9OWoE asRGo46yQfQRk789fZhiHIxvx04.zrEjtdGX.3UJ.sZihzDzwHSG6CaAXLLE q3oAWKoSPMVQNNZrmZVRbAnuU4ZjUk7iLd8iJssRBip9UoseyNLmOIMdRiux 6P6sAqqavZpZZvmx3BjkvCE5h8qFGc5mHG1gCjL3fVhvmy3_R_UPO7sn13Wy JUDAUCZFAnjTlAmypfssMPfbZLe8WNt3y_CcNoKm0_Rh8YKZ4CnbFXQ32IQd 9Mdjj6WrqKw8W3Bg3faU9i5nXj93M8w-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp103.mail.gq1.yahoo.com with SMTP; 25 Jan 2013 12:54:34 -0800 PST Message-ID: <5102F107.8090501@FreeBSD.org> Date: Fri, 25 Jan 2013 15:54:31 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130125204430.GX2522@kib.kiev.ua> In-Reply-To: <20130125204430.GX2522@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:54:40 -0000 On 01/25/2013 15:44, Konstantin Belousov wrote: ... >>> I am really tired of the constant struggle against the consumation of >>> the FreeBSD as the test-bed for the pre-alpha quality software. E.g., >>> are we fine with broken C++ runtime in 9 ? >> The libstdc++ issue is really REALLY worrying. >> I would prefer if the hack to attempt using libstdc++ as a filter >> library were reverted altogether in 9.x. >> >> I had a lots of stress with that issue as some people pointed at >> my libstdc++ updates as possible root cause. I felt some natural >> relief when the real cause was found but I certainly wonder why >> the change was made in 9.x though since it's clear that codebase >> will not be migrated to libc++. > You were finger-pointed due to the rule 'blame the last committer > from the VCS log'. Even less so, you were asked about it because > you probably knew most about possible cause. Oh, I was finger-pointed quite long ago, but I didn't find the issue until you also fingerpointed so retroactively fingerpointing was clearly the right thing to do. It was nevertheless stressful as this is a pretty critical issue. C++ is (partially) broken in a stable release! > I am not worried about the bug itself, which needs a proper > identification and fixing. I am indeed wery disappointed regarding the > attitude of the person who introduced the bug. Reverting the split may > be the best action in my opinion. Both in head and stable. I am aware a fix is being worked on. I think that as long as the default compiler/C++ library works it is OK to make things easier for other compilers. I am OK with having that change in -current but for 9.x it is simply unacceptable. Pedro. From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 21:51:24 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D34193F; Fri, 25 Jan 2013 21:51:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 11870C36; Fri, 25 Jan 2013 21:51:23 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DF48E5C43; Fri, 25 Jan 2013 22:51:16 +0100 (CET) Message-ID: <5102FE56.40806@FreeBSD.org> Date: Fri, 25 Jan 2013 22:51:18 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Pedro Giffuni , Konstantin Belousov Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130125204430.GX2522@kib.kiev.ua> <5102F107.8090501@FreeBSD.org> In-Reply-To: <5102F107.8090501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 21:51:24 -0000 On 2013-01-25 21:54, Pedro Giffuni wrote: ... > I am aware a fix is being worked on. I think that as long as > the default compiler/C++ library works it is OK to make things > easier for other compilers. I am OK with having that change in > -current but for 9.x it is simply unacceptable. Actually, clang with libc++ works fine, and both clang and gcc with libstdc++ don't... If the problem is caused by the switchable libsupc++.so backend lib, I would have no trouble with reverting that. But do we know that for sure at this point? I have not spent enough time looking deeply into the issue. I did notice that libsupc++ .So objects get linked into libstdc++.so, even while they are also in libsupc++.so. Maybe that is causing trouble? From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 22:18:22 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EAC0129; Fri, 25 Jan 2013 22:18:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 78941DE1; Fri, 25 Jan 2013 22:18:21 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA05192; Sat, 26 Jan 2013 00:18:18 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TyrbF-000G6F-PN; Sat, 26 Jan 2013 00:18:17 +0200 Message-ID: <510304A7.2000304@FreeBSD.org> Date: Sat, 26 Jan 2013 00:18:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Warner Losh Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> <510290A1.5010809@FreeBSD.org> <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> <510295E5.8060400@FreeBSD.org> <8B3FB147-6A38-4E2A-A5CA-F5EDEE1C0B5E@bsdimp.com> In-Reply-To: <8B3FB147-6A38-4E2A-A5CA-F5EDEE1C0B5E@bsdimp.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:18:22 -0000 on 25/01/2013 21:35 Warner Losh said the following: > This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free? Or was it just a goal for 'some day'? -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 22:37:26 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C09E60C for ; Fri, 25 Jan 2013 22:37:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mx1.freebsd.org (Postfix) with ESMTP id 947D4EB1 for ; Fri, 25 Jan 2013 22:37:24 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id q12so144032yhf.7 for ; Fri, 25 Jan 2013 14:37:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=nlB3PBiz0lVsgcfIv/RKanWVh+Ywn12hd8o7QYqWFsk=; b=o76PQEIp4KY2rS+cuMoo6cUlM+MSuYSZKed+PrM2mhwhK+u9WQDPaskCj58Xba9YkN cJ1LyTRBjRo/Vdmkm00VTf1l7kqee04T0P7SgkkDYZbj7D6GPI9fUm0EBTanKeBORSes JwQUlr0N4EKYFEhJfZj+NIpxvC2gMfYYAPPxjMdu1lN0vY2cW0yfVF1wa1NwmmvhLQQl 4QU5+zy+8EHRgWjTswyZsevztxfkKA+5FEpQn6dGvWDCouguIwGy9YTJRYIINe0I3r0r pK6pRZAnu3I9CK2IDLgn2p3nnREz3j2ZLky3SXUonzlVxtAxITDCkFhXjhPId+6GJR7d ILYw== X-Received: by 10.236.92.75 with SMTP id i51mr7874750yhf.64.1359153110296; Fri, 25 Jan 2013 14:31:50 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id c44sm2348156yhl.15.2013.01.25.14.31.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 14:31:49 -0800 (PST) Sender: Warner Losh Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <510304A7.2000304@FreeBSD.org> Date: Fri, 25 Jan 2013 15:31:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01F1C63C-13D7-4C9D-AF77-FE69CB6392B7@bsdimp.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <1B345827-76F0-49C7-8D54-82866938E0A1@theravensnest.org> <510290A1.5010809@FreeBSD.org> <44ED3C73-4BC0-4EFE-9072-474E6FE32B71@FreeBSD.org> <510295E5.8060400@FreeBSD.org> <8B3FB147-6A38-4E2A-A5CA-F5EDEE1C0B5E@bsdimp.com> <510304A7.2000304@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnr6z5xoBxvVrhRaWS8FLNJSLqXUUqqB37lIVg6xtp4TJtE+PPI2klo3M77vge2nOx5930L Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:37:26 -0000 On Jan 25, 2013, at 3:18 PM, Andriy Gapon wrote: > on 25/01/2013 21:35 Warner Losh said the following: >> This has been talked about in a vague way for years. >=20 > Warner, >=20 > just a nitpick, couldn't resist - sorry, so for years we talked about = the magic > 10.x release to become GPL-free? > Or was it just a goal for 'some day'? In the talks that we've had at different venues, 10.x has been a short = hand for someday. At first it was clear that it was too ambitious to be = in 9.0, then later it was a nice goal to have for 10.x, but it isn't a = show-stopper for shipping 10.0 if there's still GPL'd code in the tree. = Remove as much as possible, as fast as possible, but with the big caveat = of without removing features that mattered. clang is nice and all, but = it isn't yet a complete replacement for the tier 2/3 platforms for gcc. = It is unrealistic to expect that we'll have something that's functional = on those platforms in the 10.0 time frame, unless that timeframe is very = far in the future. Again, it is the difference between a goal (which we can fail to achieve = fully) and a requirement (which gates the release) that's the important = distinction here. Core has never set GPL-free as a requirement for 10.x. = They haven't even stated, as far as I can recall, that it is a desired = goal for the project. The goal has been driven by many stakeholders that = can't use GPL today, as well as a recognition that GPL-free is a big = selling point in some markets. The more we can do this, in general, the = better. However, the drive must also be tempered by the need to keep = current things working and not break them needlessly. Which, btw, is the whole reason full external toolchain support is = necessary. With that, we can kill three birds with one stone. (1) we can = allow users to use the vendor optimized versions of the gcc toolchain, = if they want. (2) non-tier 1 platforms could use it to build with known = good gcc/binutils versions that may live in ports. ia64 is often = mentioned here. (3) We provide a fallback for people that want to use = gcc on tier-1 platforms, but newer versions. We've only kinda sorted = solved these problems in a kludgy, error-prone tedious manner today, and = much work remains to bring the support up to the quality users expect = and need from the project. Warner From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 02:09:41 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40A6BA35 for ; Sat, 26 Jan 2013 02:09:41 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm17-vm4.bullet.mail.gq1.yahoo.com (nm17-vm4.bullet.mail.gq1.yahoo.com [98.137.177.228]) by mx1.freebsd.org (Postfix) with SMTP id D2AE78A4 for ; Sat, 26 Jan 2013 02:09:40 +0000 (UTC) Received: from [98.137.12.56] by nm17.bullet.mail.gq1.yahoo.com with NNFMP; 26 Jan 2013 02:03:49 -0000 Received: from [98.136.185.46] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 26 Jan 2013 02:03:49 -0000 Received: from [127.0.0.1] by smtp107.mail.gq1.yahoo.com with NNFMP; 26 Jan 2013 02:03:49 -0000 X-Yahoo-Newman-Id: 723118.66052.bm@smtp107.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: AVeRcv0VM1nEI7Q9hpgH5fmT9naOzaSPmke0g65Y2VB4WsM 38S5KdZmsO4FeY__2p8rKmAcsJSqz7D7eMCJf.b_kBYN_AvUZndqYKrcHxFH H.dqWenAl8AbbiaB6YZdw89kOhHhycIIl2RelnoWMOoEj_o94BDQ9X2T4fk6 1yE45NV3yHIfgfFwG_XmdqrgAkS8vQ5gk4K9ITm0Ae3dbm_2i.de3dIc7Z2a WsGPkvVSlYbmYc6WX08IZVpxnpmYlLJJah1H_KC6d8d1dG_pne6eBHY7LgB7 y6Q1HQQyXNtcrr8.VSdIm79grAPIo7XEqyYUiabrV6.OiO8z0AHktXjO5OTR RqeBgFx2JJBkcpnutl35gwMCOauXdRSkeF_t7ZRu_9nmaeswl7HCfjqJJgf9 0Q8_mmWzuIlN6nvBTd2j5F7odmwVCDs5exK08z6TvTPs_TAH9PUQYuRPwOUI TfOkA4r0R4gttewgslesggtcEYzM_Pg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Received: from [192.168.10.102] (pfg@200.118.157.7 with plain) by smtp107.mail.gq1.yahoo.com with SMTP; 26 Jan 2013 02:03:49 +0000 UTC Message-ID: <51033982.4020301@FreeBSD.org> Date: Fri, 25 Jan 2013 21:03:46 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130125204430.GX2522@kib.kiev.ua> <5102F107.8090501@FreeBSD.org> <5102FE56.40806@FreeBSD.org> In-Reply-To: <5102FE56.40806@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 02:09:41 -0000 On 01/25/2013 16:51, Dimitry Andric wrote: > On 2013-01-25 21:54, Pedro Giffuni wrote: > ... >> I am aware a fix is being worked on. I think that as long as >> the default compiler/C++ library works it is OK to make things >> easier for other compilers. I am OK with having that change in >> -current but for 9.x it is simply unacceptable. > > Actually, clang with libc++ works fine, and both clang and gcc with > libstdc++ don't... > > If the problem is caused by the switchable libsupc++.so backend lib, I > would have no trouble with reverting that. But do we know that for sure > at this point? I have not spent enough time looking deeply into the > issue. > Yes, pretty sure that reverting that commit fixes kern/171610. OTOH, theraven@ is really working on it and is near to a solution. The damage in 9.1 release was already done so perhaps we can wait a bit more for a complete fix. Pedro. From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 03:39:37 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD16082B for ; Sat, 26 Jan 2013 03:39:37 +0000 (UTC) (envelope-from lubatang@gmail.com) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx1.freebsd.org (Postfix) with ESMTP id 1AED5C03 for ; Sat, 26 Jan 2013 03:39:36 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id ge1so1758694lbb.29 for ; Fri, 25 Jan 2013 19:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JNHTfM0fMyL6Vds5n/7xv0bd5RYEbsU6XftjTu549KE=; b=o8WxpUrwJRybawHN/mZJcqnq6nZhvweeHyfMO6C55XfW8dv9vzDueisdFBIuJIyFxJ Bgi1udZZdDvku28fZ6Mtyv0hBhUGHmI/Dt0Z2PbCkb7U4gXH9bdo4pZCj/BHhUJz24vm UxDPugQtGtzczM4lmre+oxEtq+llRmaunPyDwZlh0S1GMpChLBYrtTOTQQEUKnF21kzT MNuiripPba1LIUiBsPSuWef77Y/uvZBHA9NBV9nReGodns+h50i1motk+izJVJKKf3bC cFhqXTbbxfIPe9MlQ7WjWb8Qu6EpH+pVF28RO0WCxqinXAlXVG8N9twMiq67Enp6UCy2 EtTg== MIME-Version: 1.0 X-Received: by 10.152.132.137 with SMTP id ou9mr7090924lab.7.1359171570367; Fri, 25 Jan 2013 19:39:30 -0800 (PST) Received: by 10.112.150.194 with HTTP; Fri, 25 Jan 2013 19:39:30 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 11:39:30 +0800 Message-ID: Subject: Re: [patch] crunchide breaks object files when using mclinker to do base system linking From: Luba Tang To: Erik Cederstrand Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "toolchain@freebsd.org" , pete chou X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 03:39:37 -0000 Hi, list, This patch helps not only MCLinker but also the Google gold linker to link the base system. GNU ld, Google gold and MCLinker are designed for different purposes and have different market spectrum. Letting different groups adopt different linkers for their own needs can cater BSD to various markets. Big Thanks, Luba 2013/1/25 Erik Cederstrand > Hello list, > > On behalf of Pete Chou, I would like to ask for review, testing and > hopefully commit help of this revised patch for crunchgen and crunchide > which allows mclinker (http://code.google.com/p/mclinker/) to link the > base system. In short, this patch is needed because crunchide is being > overly strict about the section layout of an object file. > > Thanks, > Erik > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to " > freebsd-toolchain-unsubscribe@freebsd.org" > From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 08:53:18 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F8A6B7F; Sat, 26 Jan 2013 08:53:18 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 725316C2; Sat, 26 Jan 2013 08:53:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 199006001; Sat, 26 Jan 2013 02:53:16 -0600 (CST) Date: Sat, 26 Jan 2013 02:53:16 -0600 From: Mark Linimon To: Pedro Giffuni Subject: Re: Removing default build of gcc Message-ID: <20130126085316.GA9021@lonesome.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5102ECBF.4060500@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 08:53:18 -0000 On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > I don't care much about gcc in current. clang, even on -9, can't build the following: - most of kde - graphics/GraphicsMagick - editors/emacs21 - www/libxul19 any one of which I would consider showstoppers for making a gcc-less system. mcl From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 10:24:15 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 991821C0 for ; Sat, 26 Jan 2013 10:24:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 52C6D946 for ; Sat, 26 Jan 2013 10:24:15 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0QAO1BJ083101 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 26 Jan 2013 10:24:02 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_4F5D6677-85BE-446F-A03E-E6C90A09BB68"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130125195941.GW2522@kib.kiev.ua> Date: Sat, 26 Jan 2013 10:23:58 +0000 Message-Id: References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 10:24:15 -0000 --Apple-Mail=_4F5D6677-85BE-446F-A03E-E6C90A09BB68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: > I am really tired of the constant struggle against the consumation of > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > are we fine with broken C++ runtime in 9 ? Please can you stop the FUD here? It really isn't helpful. We have a = working C++ runtime in 9.1: libcxxrt. In fact, we have a working C++11 = stack in 9.1, with the combination of libcxxrt, libc++, and clang++. = Unfortunately, the filter library configuration for libsupc++ left some = symbols in the wrong symbol version (the ABI library version instead of = the STL library version) and so there are some issues in corner = cases[1], which I am working on fixing. I have a fix for the most = common corner cases, but I want to make sure that I have caught all of = them before I commit. This will happen tomorrow. The filter library is very important to have working for 10.0, because = we will need the ports and compat versions of libstdc++ to use it if we = want to be able to mix code that uses libstdc++ (i.e. any ports that = don't work correctly with libc++) and libc++ (i.e. any ports that use = C++11, which is going to be an increasing number over the next few = years). =20 David [1] In particular, terminate handlers are not correctly set, and = exceptions thrown from the runtime library are not of the expected type. = This means that C++ code that calls std::set_terminate() will not work = and neither will code that calls __cxa_bad_alloc() and friends and then = tries to catch the resulting exception. The only code I have seen that = actually does this is a test case that I wrote for libcxxrt. In = general, code encountering either of these problems is already in a very = broken state and the only difference you will see is a less helpful = error message before it crashes.= --Apple-Mail=_4F5D6677-85BE-446F-A03E-E6C90A09BB68 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRA66+AAoJEKx65DEEsqIdUtMQAInmdXR3D6gkrIuvzK86wBZe Hfx+8afPJFACQSL+rkkN/ZbyppnZzlJTcr8HRVubMXQIytOLfbZCj9HxdW5aWfgW jkmnOkuB9+PheOXGd5dmDwvgwVpSILYC5u4k73WnZ3gHXPbnkv7m8EIGMtxSg7Kl hiKAu8GWz7LIMZbE4BVsHYPtdRbTH1QlfrIt83iHEr8ZlEQUAtgfwGqzl+znbAue Pc1W1PdBuTtv9NFQ3lqj+3lTLL37o3086Khk4LCTA0EImwnIbl8kXGY9pwQIXdi9 8AHFQdOIchsLYR0ZLjkyJtJvNLUzyPfkT79g0kvvPjSyriCY4Whbk+JrvSfma3fA 4QdDoeYzHREmZw9xxo3+lmeMkgWA8oUxcx1JGsvmj1w+FLvEeHvVBUTJCYqoINcO ai6gBdp+AZd++wCvC6Bwl+I4xdxkNXcEUNMOigFNw+RDI5zocdGip1abmpbSzGR4 s7kJnCHQdiAdi0Lt3c3w8LlX38OR+g2NJe5NVhN+zhvVgKkxtXKRkXmwOjNT9Dvx U6aud/ZgfonCVSkhtcZ/UokVA3bInatEpfStVF3wd90ya/Y7ZZv1amFB6gdIsFo5 +MTisi0gz8AOtD05GDfe8Ydk6OIydSe4oalbN4nDTAdh6iDWY1k7TqNcVDeCcdDF lsfJvPpGE6Vbq/0cKtF7 =ybRO -----END PGP SIGNATURE----- --Apple-Mail=_4F5D6677-85BE-446F-A03E-E6C90A09BB68-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 12:29:03 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE0EA95F for ; Sat, 26 Jan 2013 12:29:03 +0000 (UTC) (envelope-from giffunip@yahoo.com) Received: from nm16-vm1.bullet.mail.bf1.yahoo.com (nm16-vm1.bullet.mail.bf1.yahoo.com [98.139.213.131]) by mx1.freebsd.org (Postfix) with SMTP id 3F0FEDA7 for ; Sat, 26 Jan 2013 12:29:02 +0000 (UTC) Received: from [98.139.212.151] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jan 2013 12:28:56 -0000 Received: from [98.139.212.240] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jan 2013 12:28:56 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 26 Jan 2013 12:28:56 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 479328.83275.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 72516 invoked by uid 60001); 26 Jan 2013 12:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1359203336; bh=pLzhEXc9qWCt3dv/EHdJrdntaZcuVJjYfgTtD/TC6So=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=WLzIy/S1/MB2cAMehHnYrpwxwwRUweQTkDh8u6sn1yuMKThNNaldhAO+1mG2h4ojx/gwoDFCc8PqSyfXQTW82NywaDifouv1G/IL7kAuH1dagcxyliHn0iLwuke/5lsNRxjAoJTvS8Cg0yEoYhAgX5AIb2/MGMwcevzvlV1Yk4A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ABuHahSvy4gQ3XQUa8tyMAu9LjYRB5JWXoH8/QsBd2CsF5KVI7rZE8wDXtt4yGyECHkEnWCWbiPZ2N2XzLcr4JATNxRrykKwN0KPBa958VNbykoZPRXNkEIbcZkCo7AhJYbbLDz2ULJpLFttr6clH5Wy38OH1A4YBTzuACUs+ow=; X-YMail-OSG: dIAzsJkVM1nqL9Wq7RJS2htJVllenvOHuuWsZGxGdqJ7pL4 DB2jj6pMZxhngw3R7YhSg_YuMA.pRhJYWtU8BEvewx_RIfl3TrVd0FFI.NLJ NT7atLNbeTCBx4.Wq..zNnZAXhjzKuYbQUDEbMkfACzmuBLl6mqkbK5TzblY 1UZ4vseNMZPjCkwD1MJ_y9qA.qIFkL4W9t7H6oFa5dMou6U8_ZDQdUt_m6PV XsDQUOdZGuvhK2Ed6z3aHthaJri4HdIFcv0HTVCOom7QmQH1v66tFqOcPci4 FH3ZaH.1zsm_eqJq80s49Px1d9fCDK7kMDuM5yyoDqHidpRCXibyMNqzURqC zKiSU3anxVGlhBXFol1JQ2r95o5jer5YHgFvsi7PirzOkC.uHF_EYzUswlTl AXuExfON6Sptj1yUeprAz4IXeK3oXsv0D5Gm46OLT.sq0GcLXKlLQdQ7HgXU U14EpPipp8yNHg1R3THMyhxtHmF3IHPIBLzImGt3TOzroHkH2_HGmCrQ- Received: from [200.118.157.7] by web162105.mail.bf1.yahoo.com via HTTP; Sat, 26 Jan 2013 04:28:56 PST X-Rocket-MIMEInfo: 001.001, SGVsbG87CgpTb3JyeSBmb3IgdG9wLXBvc3Rpbmc6IEkgYW0gaW4gYSBtb2JpbGUgZGV2aWNlIHRoYXQgZG9lc250IGtub3cgYmV0dGVyLgoKSSBhbSBhd2FyZSB0aGF0IG9wZW5vZmZpY2UgaXMgYWxzbyBicm9rZW4gZHVlIHRvIHN0bHBvcnQuCgpUaGUgc2l0dWF0aW9uIGlzIG5vdCB0b28gZGlmZmVyZW50IGZyb20gdGhlIGZvcnRyYW4gcmVtb3ZhbDogZm9yIG1hbnkgcmVhc29ucyBpdCBpcyBjb252ZW5pZW50IHRvIHVzZSBhIHByZS1wYWNrYWdlZCBjb21waWxlciBmb3IgbWFueSBwb3J0cy4gR2NjIDQuMi4BMAEBAQE- X-RocketYMMF: giffunip X-Mailer: YahooMailWebService/0.8.130.494 Message-ID: <1359203336.70140.YahooMailMobile@web162105.mail.bf1.yahoo.com> Date: Sat, 26 Jan 2013 04:28:56 -0800 (PST) From: Pedro Giffuni Subject: Re: Removing default build of gcc To: Mark Linimon MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 12:29:03 -0000 Hello;=0A=0ASorry for top-posting: I am in a mobile device that doesnt know= better.=0A=0AI am aware that openoffice is also broken due to stlport.=0A= =0AThe situation is not too different from the fortran removal: for many re= asons it is convenient to use a pre-packaged compiler for many ports. Gcc 4= .2.1 is also becoming obsolete and is really difficult to maintain..=0A=0AP= edro. From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 15:22:37 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99153BF8; Sat, 26 Jan 2013 15:22:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E9FA132E; Sat, 26 Jan 2013 15:22:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0QFMQ0k068582; Sat, 26 Jan 2013 17:22:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0QFMQ0k068582 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0QFMPBX068581; Sat, 26 Jan 2013 17:22:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Jan 2013 17:22:25 +0200 From: Konstantin Belousov To: David Chisnall Subject: Re: Removing default build of gcc Message-ID: <20130126152225.GC2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEkl9o9W2JhK2ndV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 15:22:37 -0000 --lEkl9o9W2JhK2ndV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2013 at 10:23:58AM +0000, David Chisnall wrote: > On 25 Jan 2013, at 19:59, Konstantin Belousov wrote: >=20 > > I am really tired of the constant struggle against the consumation of > > the FreeBSD as the test-bed for the pre-alpha quality software. E.g., > > are we fine with broken C++ runtime in 9 ? >=20 > Please can you stop the FUD here? It really isn't helpful. We have a > working C++ runtime in 9.1: libcxxrt. In fact, we have a working C++11 > stack in 9.1, with the combination of libcxxrt, libc++, and clang++. > Unfortunately, the filter library configuration for libsupc++ left > some symbols in the wrong symbol version (the ABI library version > instead of the STL library version) and so there are some issues in > corner cases[1], which I am working on fixing. I have a fix for the > most common corner cases, but I want to make sure that I have caught > all of them before I commit. This will happen tomorrow. > > The filter library is very important to have working for 10.0, because > we will need the ports and compat versions of libstdc++ to use it if > we want to be able to mix code that uses libstdc++ (i.e. any ports > that don't work correctly with libc++) and libc++ (i.e. any ports that > use C++11, which is going to be an increasing number over the next few > years). > > David > > [1] In particular, terminate handlers are not correctly set, and > exceptions thrown from the runtime library are not of the expected > type. This means that C++ code that calls std::set_terminate() will > not work and neither will code that calls __cxa_bad_alloc() and > friends and then tries to catch the resulting exception. The only code > I have seen that actually does this is a test case that I wrote for > libcxxrt. In general, code encountering either of these problems is > already in a very broken state and the only difference you will see is > a less helpful error message before it crashes. I do not see how the code demonstrated as failing in standards/175453 could be classified as 'broken' or 'so special that nobody does it'. It is perfectly valid, and my reaction for such breakage is that C++ runtime is completely broken. How pointing to this fact can be FUD ? Your initial assesment of the problem as a misbehaviour of the combination of filtering and versioning made no sense to me, I asked you to provide the isolated test case, which you did not. Our implementation of filters indeed only allows for the filtered symbol to have the same version as the filtee symbol. I re-read the SUN documentation about filters (who had designed them), and looked at what Linux does there. It seems to me that Sun document spirit forces us to behave in a way which our rtld currently does. Linux behaviour is useless there, IMHO, since their rtld just inserts filtee before filter in the global lookup order (I may be wrong there). I do suggest (again) that the way to fix the issue is to provide the isolated test-case and decide if the behaviour of rtld is right. If we conclude that the problem is not in rtld but in the versioning mismatch between libraries (libstdc++ and libsupc++), I again suggest to provide the patch for review first. The ABI seems to become too unwieldly, and making ad-hoc changes there could paint us into the corner. --lEkl9o9W2JhK2ndV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRA/SxAAoJEJDCuSvBvK1BnC0P/jFDdLKWB5ncHbwYEuKgsWAL LXdCOTtHkw4NI2mqpudFpg/qhHK2KWZ4RDpACQJnVuzKRdl7KeH5mLtpmMAG02YW l1KQbXQhGjhuNZBPF5MSSPo0b1T8iL79oM5pSdfI5EUa2J5CRrCr9fsTtqDL4TLK XE9kaL5VMjGCagi4I4yJCGA0fcDmUDWqS5vxILt5D8ej/cn4GTg9xC7Z2BOcCCnU 0ssAen+dsVhoBBKOo1BmEaUE6AhnwKZ2dZRuiTviWknz950pDFowu9eNqOv4vCY6 ZfXyjnU4N2qw0/8mDkzK9CZG3CkevGbuFArgLkF5jUnmOyB4bHSv2rg9he167DIp wHhyqWRJuA7gH7sYDE6oFMEvcScdUoQOag7p4/sjQ/xTUu2Iwyngh6R+heubI2M/ e1wQzldWLMJZCHAvzz0d9gvtdJ1Kh/FNqM7mg6WH5stP7P5hbBxmmKSwarDsTBbl 5NAADs795rq/StR2S+Ie2XendBfp0PGlEuM2DwLJuWGj3gnBkzhToHfB0ZzmO1A8 sCGtpe+h658XE1kuHa2xOz7TRxCYvcaqrOV6PGQe5EqOcCnyqkKKFiQK98Ui7q1l DNEwoFE7wuYaSI3v0R+EjA+gvIzabhBKQrGgJh0rE7uim+zzGIZVygngdI/HOBts K0LqjqnKFaHHfemZTwTv =eJqe -----END PGP SIGNATURE----- --lEkl9o9W2JhK2ndV-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 15:24:32 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EACF0C2E; Sat, 26 Jan 2013 15:24:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 619F633B; Sat, 26 Jan 2013 15:24:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0QFOS9v068594; Sat, 26 Jan 2013 17:24:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0QFOS9v068594 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0QFORDf068593; Sat, 26 Jan 2013 17:24:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Jan 2013 17:24:27 +0200 From: Konstantin Belousov To: Mark Linimon Subject: Re: Removing default build of gcc Message-ID: <20130126152427.GD2522@kib.kiev.ua> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130126085316.GA9021@lonesome.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FBzHcVv9FDoUuQV5" Content-Disposition: inline In-Reply-To: <20130126085316.GA9021@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Pedro Giffuni , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 15:24:33 -0000 --FBzHcVv9FDoUuQV5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 26, 2013 at 02:53:16AM -0600, Mark Linimon wrote: > On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: > > I don't care much about gcc in current. >=20 > clang, even on -9, can't build the following: >=20 > - most of kde > - graphics/GraphicsMagick > - editors/emacs21 > - www/libxul19 >=20 > any one of which I would consider showstoppers for making a gcc-less > system. IMO this is not the approach we should take in regard to gcc and ports. Ports should use port-provided compiler, and be untangled from the base toolchain. I believe that forcing ports committers to port 20K+ packages to clang is a waste of the FreeBSD resources and is is destined to fail despite the efforts. --FBzHcVv9FDoUuQV5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRA/UqAAoJEJDCuSvBvK1B7X8QAIypT67Uir4Luya72KhWBAdn O/k0z8Fs81CgfuxGygj/mLaLMj65WFqbkeSEEx+IdPPvbOgz5+ZTvcH8FjV8Al7Z HpV5yZ9PaBMDfex6n+qMddyN5OLLvzSXKgBk1N2hTWneLYHwXkEvWRqybrshxDca 9aSDyPMC3/S4rCyjRqVqov9qT5n3rcwrAw6JhZrI+YMMIVXgAW4Pi8kvZwTcdvjD aHhYNiinVFjhiNEIjfSXWZzwLzoJ1qWWJ4vsNt2e/jiBB1sm0HIBkPobCoLgp5eK mhnd/pQDHREMu7OoNFsvfn2ngdXgp92UTc34YlpDNq/cZdUoIQRbp3AdwrNNMRiT f62RiYWuK7V76t0SCYwJoJCHtrix5sze8/YQj0eek8bNjs/2+CpfXrmc+Gx9JCvM jRL9LzIkRoOgx13lPv3DyTiZG23uWhnz77UsvjLpIBM3LzgWAY9yKoALxik12UYX CBPkISmUrACI7LUbDayWupb9JlEnNa1whg4TEBEXmrsGEcsadSLwsIwbI3CbL7sy wgZ8JmfVq4CpgTwLwjlm+ZeVqXSUxd+ZFpYPw4bwRZ4NgijvFwGVizVAD17fyeD9 jbU/QlwZmvXnEtw/uE7ScITZgaqiCuo5a65o25hs6Ep9b7UGVQoPYxlv9T8IckOE KUlBoFhvuMcg7AStP440 =GfxB -----END PGP SIGNATURE----- --FBzHcVv9FDoUuQV5-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 16:14:00 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24FA93AE for ; Sat, 26 Jan 2013 16:14:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id ECCBE696 for ; Sat, 26 Jan 2013 16:13:59 +0000 (UTC) Received: by mail-ia0-f174.google.com with SMTP id o25so2168108iad.5 for ; Sat, 26 Jan 2013 08:13:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=dvXbG7y3e/NgHacQ+4S0JAInYjcPfJy8s3x7N3iE1Vk=; b=mPNHp6j7vLwXKKiFN1EIUkiSgiCUHsK3Sx3EggTyWPpGxS8iQ8Fa/iWrDBX9ZrJNGx POn8vcrMsQ55dyz2HpjppUYVyvsBNGfuiM5sYXpjr9s9ytsSedwROoYwaoBmvVPvrKKi L+FVLdWvBcXBkbHgOqgKSpEY/6r7tevG+3WQ7tgMLr40se2TAt9P4G8ReEUGBTKNL7gd KV+OmbveRG68MyRtahZgTGtP9YmXewCQbh8nM9GWRLt4ztaUXBCcpuSZGGq7v4gyUZiZ dustCH9zNOE1qXf9KKhzaebRzTTTpFQCoaPfk+Oank90bS71oU5owf15ST5hYUfnk9cm WojA== X-Received: by 10.50.106.134 with SMTP id gu6mr1369123igb.78.1359216838426; Sat, 26 Jan 2013 08:13:58 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id b13sm1841560igp.7.2013.01.26.08.13.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 08:13:57 -0800 (PST) Sender: Warner Losh Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1359203336.70140.YahooMailMobile@web162105.mail.bf1.yahoo.com> Date: Sat, 26 Jan 2013 09:13:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1359203336.70140.YahooMailMobile@web162105.mail.bf1.yahoo.com> To: Pedro Giffuni X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm94LPa1qiksSb7TeQFjLJY3Uvi0DwmY8GMQG76CeWeI5ujfPX72GKG2RU28t/53oforAN4 Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:14:00 -0000 On Jan 26, 2013, at 5:28 AM, Pedro Giffuni wrote: > The situation is not too different from the fortran removal: for many = reasons it is convenient to use a pre-packaged compiler for many ports. = Gcc 4.2.1 is also becoming obsolete and is really difficult to = maintain.. Removing it before all the pieces are in place is even more disruptive. = They aren't there, and we need to get people to fix the broken stuff = first. Warner From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 16:50:10 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA2EEAC5 for ; Sat, 26 Jan 2013 16:50:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8B830777 for ; Sat, 26 Jan 2013 16:50:09 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0QGZbIJ085065 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 26 Jan 2013 16:35:38 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130126152225.GC2522@kib.kiev.ua> Date: Sat, 26 Jan 2013 16:35:31 +0000 Message-Id: <8A0C6AD5-F247-4488-B44A-85AC2D539D4D@FreeBSD.org> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <20130126152225.GC2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:50:10 -0000 --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Jan 2013, at 15:22, Konstantin Belousov wrote: > Your initial assesment of the problem as a misbehaviour of the = combination > of filtering and versioning made no sense to me, I asked you to = provide > the isolated test case, which you did not. The test case in the PR was such a test case. libstdc++ and libsupc++ = export a few symbols (including the ones that I mentioned in the email = that you are replying to) with different versions. The end result is = that you get some cases where some code (typically in libsupc++)=20 I am not claiming that this is an rtld bug, so I don't know why you keep = going on about it as if I am. I do not know why you want me to provide = you with an isolated test case for a bug that is assigned to me and that = I am in the process of fixing. > Our implementation of filters indeed only allows for the filtered > symbol to have the same version as the filtee symbol. I re-read the > SUN documentation about filters (who had designed them), and looked at > what Linux does there. It seems to me that Sun document spirit forces > us to behave in a way which our rtld currently does. Linux behaviour = is > useless there, IMHO, since their rtld just inserts filtee before = filter > in the global lookup order (I may be wrong there). This is COMPLETELY IRRELEVANT to the bug in question, which is that our = libcxxrt and libsupc++ version scripts have some incorrect symbol = versions. > I do suggest (again) that the way to fix the issue is to provide the > isolated test-case and decide if the behaviour of rtld is right. It is correct. I am not claiming it is incorrect. I don't know why you = keep repeating that I am. =20 > If we > conclude that the problem is not in rtld but in the versioning = mismatch > between libraries (libstdc++ and libsupc++), I again suggest to = provide > the patch for review first. The ABI seems to become too unwieldly, and > making ad-hoc changes there could paint us into the corner. I have a patch, which fixes it in some cases and has been tested, but = misses some others. I am preparing a patch that fixes the versioning = consistently across libsupc++ and libcxxrt to match libstdc++. I want = to do this as a single patch, rather than an ad hoc series of changes. = My aim is, as it has always been, to preserve the existing ABI.=20 David= --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9 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----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRBAXTAAoJEKx65DEEsqIdbcsQALSJ8dbfVWKtXszQc+p6wJG2 cA4mHmRaeDUBcJ0iCwIQQhtwysmYLZ3varoPoOs/2GDZI1LXxXlmThbjOyn57K3x 2GtKju7UaZFxxcWBfEvv5Je4gUXpXDUxuqtzbalMKjHFrrkFRvDLv2z1P57md5Aa 3BxMmg3cnq41qcHdq2Uepq+Vg87UCo76MHGgs9JR5CWSVDqG9FYEu+rZG7Pcr/jd cYRoX/GuG+GCvzJnEc7i/eSPmJD1YhMG6qHPw9lXlewo0nehg0HBENgfhFr5AHo9 /02mD5XzoI3BI8RfeeUKNDkhrPdeqEXR8K5eDvzjf73eCke5kQ1jQio6zhx/O/2Q FHpQ5MXfOeRGsXdjeshktUSgJFH6N5ToepO2EcJ8E4x7y+I82E5ylU2b1OCJ/DGZ H/4zIXw852oXF8Fua4qeIIGOufQirBAY5xY2Bm4Bd/QN6k89NKb7e7e2MP6CSumz Q6GM4TPDI+Ixvvmi5tF7lPyrYaLDDCChWBZK5oAeifLh7yAV6u49T4ykQ81QjTtj 4LiyvRxf03u1yeioX8MKwzJ3ITrcamRlQCcJzrDLThGS9uBNWRefYf32yq3tAeZt wtE/WdDngiivL0OS9a0cGn8FB7tVcRiyv+NxPChj6v2tPQK2uZN1x+ZZmrB+rtt6 UNSN371KvxhVl3jL9mGq =HW4T -----END PGP SIGNATURE----- --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 18:05:53 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 462EAF5A; Sat, 26 Jan 2013 18:05:53 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 10E5F9EB; Sat, 26 Jan 2013 18:05:52 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 720F36001; Sat, 26 Jan 2013 12:05:48 -0600 (CST) Date: Sat, 26 Jan 2013 12:05:48 -0600 From: Mark Linimon To: Konstantin Belousov Subject: Re: Removing default build of gcc Message-ID: <20130126180548.GA3362@lonesome.com> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130126085316.GA9021@lonesome.com> <20130126152427.GD2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130126152427.GD2522@kib.kiev.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Pedro Giffuni , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 18:05:53 -0000 On Sat, Jan 26, 2013 at 05:24:27PM +0200, Konstantin Belousov wrote: > Ports should use port-provided compiler, and be untangled from the base > toolchain. And when I get the use of the build cluster back, it's one of the bits of code I intend to work on. But we're not going to be able to do that in the near-term. mcl