From owner-freebsd-arch@freebsd.org Sat Oct 7 08:24:18 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 75696E31C62; Sat, 7 Oct 2017 08:24:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06B8D63DD8; Sat, 7 Oct 2017 08:24:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v978OBvK096483 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 7 Oct 2017 11:24:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v978OBvK096483 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v978OBnY096482; Sat, 7 Oct 2017 11:24:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 7 Oct 2017 11:24:11 +0300 From: Konstantin Belousov To: John Baldwin Cc: Poul-Henning Kamp , "freebsd-arch@freebsd.org" , Baptiste Daroussin , freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171007082411.GU95911@kib.kiev.ua> References: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2706092.qpavixPdKK@ralph.baldwin.cx> User-Agent: Mutt/1.9.1 (2017-09-22) 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 autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Sat, 07 Oct 2017 08:24:18 -0000 On Fri, Oct 06, 2017 at 04:21:05PM -0700, John Baldwin wrote: > On Friday, October 06, 2017 04:47:48 PM Poul-Henning Kamp wrote: > > If we allow C++ in libc, it should not merely be for the convenience > > of a few programmers, but because we have a vision for how it that > > makes the world, or at least FreeBSD, a better place. > > > > Having C++ in libc is no trivial detail, there is a number of areas > > where this causes bootstrapping issues and conflicts. > > > > We can solve those issues with unsightly local hacks, most > > notably a bogo-malloc to malloc while C++ constructs jemalloc. > > > > But hand on heart, we all know that is a bad idea, all of us have > > been down that road before, and we also know that there is no way > > to be a little bit pregnant. > > > > The other way, the right way, to accomodate the jemalloc request > > is to go all in. > > > > Nothing in the ISO verbiage says that you cannot have C and C++ > > runtimes in the same library, as long as your linker knows the zip > > code of it. > > > > Libc as a combined C and C++ runtime can be implemented a lot cleaner > > than a libc which hides C++ components in the closet. > > > > So that is my input to this question: > > > > Either we tell the jemalloc people "sorry, it's called libc for a > > reason" or we decide to make our libc a native C *and* C++ runtime. > > > > I see no sane or even possible "middle ground" or compromise position. > > Hmm, I don't quite agree. I think it's possible to use a restricted C++ > (no rtti, no exceptions, no STL) such that you are only using language > features like templates or 'auto' without requiring runtime support. I > think that is the requirement we would place on the jemalloc implementation > for it to remain in libc. This is a requirement not only on jemalloc, but also on the compilers. I am much more worried about C++ compiler's runtime requirements than the ability of the jemalloc developers to restrict used language features to the subset which does not need some external support _at the current compiler version_. Seeing the route that clang took making C compiler unusable for normal work, I am just sure that clang++ would cause a lot of troubles if we ever try to rely on the undocumented and unpromised detail of the current implementation. > Right now the C++ runtime is split into a > couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti > / exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* > along with intrinsics from compiler-rt). All of these are variable in > some sense (if you wanted to build a GCC-based system you might want to > use libstdc++ instead of libc++, libgcc_s already varies by platform, > and upstream in LLVM there is already a libcxxabi alternative to libcxxrt > plus the GNU libsupc++). > > I think bundling any of those pieces into libc makes our system less > flexible and different from all the other UNIXy systems currently in > vogue. This also hits the ABI stability hard, see my other reply.