From owner-freebsd-arch@freebsd.org Fri Oct 6 07:20:11 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95FDBE2EE68; Fri, 6 Oct 2017 07:20:11 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F0707231F; Fri, 6 Oct 2017 07:20:11 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by freefall.freebsd.org (Postfix, from userid 1235) id C49351C8C0; Fri, 6 Oct 2017 07:20:10 +0000 (UTC) Date: Fri, 6 Oct 2017 09:20:10 +0200 From: Baptiste Daroussin To: John Baldwin Cc: freebsd-arch@freebsd.org, "freebsd-arch@freebsd.org" Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> References: <2116882.XEKuxOb729@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hxaughgijyfspz4y" Content-Disposition: inline In-Reply-To: <2116882.XEKuxOb729@ralph.baldwin.cx> User-Agent: NeoMutt/20170912 (1.9.0) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 07:20:11 -0000 --hxaughgijyfspz4y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > > I'd like to start a conversation about the viability of making C++11 a = hard > > requirement for bootstrapping FreeBSD and setting a specific deadline f= or > > doing so. > >=20 > > This discussion is motivated by an ask from the jemalloc folks to use a > > limited subset of C++11 inside of malloc in such a way that is C safe (= so > > the C programs wouldn't bloat with a C++ runtime). That's an ongoing > > discussion in another forum, and isn't appropriate for this thread beca= use > > this has become a frequent request (but if you have opinions, please fi= nd > > the thread in current@ about it). I don't know the timeline of their pl= ans > > to do this. > >=20 > > I'd like to take the rather vague plans we've had "before 12" and creat= e a > > timeline for removal of gcc 4.2 coupled with a requirement for support = in > > clang or a working external toolchain. This requirement would be coupled > > with the requirement that the external toolchain support C++11 construc= ts. > >=20 > > I'd like to propose we do this 12/31/17. Any architectures that can't m= eet > > this timeline will be disconnected from universe at that time and delet= ed > > 3/31/18. > >=20 > > It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are > > ready for this change and mips* would be ready for this change with an > > external clang toolchain. I'm unsure of riscv and sparc64, but suspect = that > > a newer version of gcc as an external toolchain could work. >=20 > In-tree clang 5.0 for MIPS mostly works (modulo some small patches). How= ever, > it requires external ld.bfd. I know that there ld.lld can link a working > mips64 world with some patches (notably the multigot patch). mips works = fine > with external GCC. riscv is already using external GCC that is C++11-cap= able. >=20 > The problem with external GCC is that you can cross-build a world + kernel > just fine and get a working system via CROSS_TOOLCHAIN=3Dfoo-gcc. Howeve= r, > that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ > started on ports to cross-build binutils and gcc packages via the base/* > ports, but those are not yet finished / fully tested. I don't think anyo= ne > has thought about how release builds will work either with only an extern= al > toolchain available. (I'm pretty sure sparc64 has booted fine with > external GCC, it's just in the same boat as mips with regard to /usr/bin/= cc.) Actually I did test those and they were working (tested in qemu) they were working fine. I have given up working on them due to the lack of interested= by the community (by interest I mean people really testing, working on it, not= just saying "hey nice sounds cool"). As for the boot when I initially worked on external toolchain sparc64 was my guinea pig and so yes it worked an booted just fine. >=20 > Also, if you svn rm contrib/gcc you will nuke all of our systems because = we > still use 'crtstuff.c' from there on all architectures for part of the C > startup code. emaste@ has looked at a replacement for that from NetBSD in > the past but I'm not sure what state that is in currently. >=20 > Another concern is fully replacing the compiler support libraries (libgcc= and > friends). Some of those also come from contrib/gcc. For mips I have some > patches in review upstream to add mips to LLVM's libunwind (which allows = mips > to use that for libgcc unwinding). I think sparc64 might be the only oth= er > architecture not using llvm libunwind. (Fixing that is a much smaller li= ft > than fixing clang on sparc64 btw, and I've successfully used llvm libunwi= nd > on mips worlds that are fully compiled with external GCC.) >=20 > That said, I definitely support the goal of requiring C++11. I will happ= ily > start using it myself in some userland bits (truss for example could bene= fit > from std::unordered_map<>) once it is available across the board. >=20 > 12/31/17 might be a bit aggressive given the holidays at the end of the > quarter, but we can start with that and revisit if need be. >=20 I'm fine with that date. Best regards, Bapt --hxaughgijyfspz4y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlnXLqcACgkQY4mL3PG3 PlrvUw//b+q++HQ/9nxMifoWutZk00Z42OThSJwiKbg4yAkmVz27OBgqCsUlOLZP SubeiDoMgkACOsZcB0j0yS/uF/NuUH/t4bAyHokmXF1u+CIB/CDZcq1WI0QkaUce nDYFPT42lMugCTdFbzFYT0H2XlBZt6+U9pr56eRVMdGSJHs44lVg1rY1ZHho6Gx/ 1Jb3q8Jt+sSJiu2VsAwDL7hQHa8ViBa4NuMqNl9U1e0lQYJTryQGuLf1VCl4tdnD 8BvzyGJFDJfgMLTk8BM11+mtyhOCgWXlpccjHASUgJgDrIXVpUc4svPluUD8K12d Q/BiWROAjfnDC/ZRp3C9FAqzYK9dMRRhPn8VC8Ufx/W5KJE4Hr5XphCDpVMDO3Ac CuDUgpSsHTjsCUUeHqshqD33/jaVu1wszka7m1QSVMTX7bfp2dgqcsOx/3pwHGFO tAuQrauxI1irsuNrJT1EhpWMXtKksL4hmXrcI/kAetVLhmhmrtpneGg5fM515BCL +dAllB8AoaT9GcYdpunVA7QWloKxOV3BwXSXjc8zgMqD2XxZe0GNAkWws6Pli9KQ SbaTG5tIwfc7aGGvwXieJW8DuNOcd1EByOEaxIaAK7lFwmqiE9BV2kjLpoY+JovE Fu/zItcMJFOuVRK2LKy713kbC3CbNyo2sk22zDmPXNu2whl4phg= =M5s0 -----END PGP SIGNATURE----- --hxaughgijyfspz4y--