Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Oct 2017 16:47:57 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-arch@freebsd.org
Cc:        Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: Making C++11 a hard requirement for FreeBSD
Message-ID:  <2116882.XEKuxOb729@ralph.baldwin.cx>
In-Reply-To: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com>
References:  <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 for
> doing so.
> 
> 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 because
> this has become a frequent request (but if you have opinions, please find
> the thread in current@ about it). I don't know the timeline of their plans
> to do this.
> 
> I'd like to take the rather vague plans we've had "before 12" and create 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 constructs.
> 
> I'd like to propose we do this 12/31/17. Any architectures that can't meet
> this timeline will be disconnected from universe at that time and deleted
> 3/31/18.
> 
> 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.

In-tree clang 5.0 for MIPS mostly works (modulo some small patches).  However,
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-capable.

The problem with external GCC is that you can cross-build a world + kernel
just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc.  However,
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 anyone
has thought about how release builds will work either with only an external
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.)

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.

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 other
architecture not using llvm libunwind.  (Fixing that is a much smaller lift
than fixing clang on sparc64 btw, and I've successfully used llvm libunwind
on mips worlds that are fully compiled with external GCC.)

That said, I definitely support the goal of requiring C++11.  I will happily
start using it myself in some userland bits (truss for example could benefit
from std::unordered_map<>) once it is available across the board.

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.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2116882.XEKuxOb729>