From owner-freebsd-current@freebsd.org Fri Oct 6 05:05:16 2017 Return-Path: Delivered-To: freebsd-current@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 739E7E27440 for ; Fri, 6 Oct 2017 05:05:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 2C4E96E9DE for ; Fri, 6 Oct 2017 05:05:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2303 invoked from network); 6 Oct 2017 04:58:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Oct 2017 04:58:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 06 Oct 2017 00:58:34 -0400 (EDT) Received: (qmail 19245 invoked from network); 6 Oct 2017 04:58:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Oct 2017 04:58:34 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CD546EC94C3; Thu, 5 Oct 2017 21:58:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc Message-Id: Date: Thu, 5 Oct 2017 21:58:33 -0700 To: Warner Losh , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 05:05:16 -0000 Warner Losh imp at bsdimp.com wrote on Thu Oct 5 21:01:26 UTC 2017 : > Starting in FreeBSD 11, arm and powerpc are supported by clang, > but not super well. For FreeBSD 12, we're getting close for everything > except sparc64 (whose fate has not yet been finally decided). My understanding of the powerpc and powerpc64 status follows. This is based on my use of head via clang as much as I can for them. For TARGET_ARCH=3Dpowerpc64 and TARGET_ARCH=3Dpowerpc : lld is far from working last I knew. (I've focused more on the compilers for testing, using other linkers and such.) [lldb may be in a similar state for powerpc64. It does not build for powerpc.] clang 5 (and 4) generated code crashes on any thrown C++ exception. For example: #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } crashes. Luckily most kernel and world code that I actively use does not throw C++ exceptions in my use. But devel/kyua is majorly broken by the C++ exception issue: It makes extensive use of C++ exceptions. In my view that disqualifies clang as being "close": I view my activity as a hack until devel/kyua is generally operable and so available for use in testing. clang 5 currently can not build the TARGET_ARCH=3Dpowerpc kernel. (I was able to back in clang 4 days --but the resultant build failed to execute init fully after finishing the prior boot activity.) For the 32-bit context I use gcc 4.2.1 for building the kernel and clang 5 for building the world, system binutils=20 in use in both cases. I do build the kernel and world for TARGET_ARCH=3Dpowerpc64 via system clang 5. But I use ports binutils as well in order for this to finish and work overall. As for more modern devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc) versions being used to build the world and kernel for powerpc64 I've never been able to get lib32 on powerpc64 to work via such a build: it builds but fails to execute from dereferencing via an R30 that has an inappropriate value for the attempt ( lib32/crtbeginS.o code in _init in /usr/lib32/libc.so.* ). (The clang-based builds do not have this problem.) It has been a while since I've done devel/powerpc64-gcc experiments. I'm not aware of a devel/powerpc-xtoolchain-gcc as an alternative for 32-bit powerpc targeting. You may want to skip the below src.conf's and so reading the rest of this note. Example src.conf for targeting powerpc64 for buildkernel and buildworld via clang: (Note: most of my more recent activity has cross built from amd64 instead of doing self-hosted. That way more folks can try the same for issues where builds stop.) # more = ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # # Avoid converts between pointers to integer types with different sign = [-Werror,-Wpointer-sign] # and such from blocking the build. WERROR=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 # # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX # binding automatically. # XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld .export XLD .endif For powerpc via clang (world anyway): # more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D As for powerpc64-xtoolchain-gcc targeting powerpc64: # more ~/src.configs/src.conf.powerpc64-xtoolchain-gcc.amd64-host TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Avoid db_trace.o getting: # calling '__builtin_frame_address' with a nonzero argument is unsafe # as an error? Other such points as well. WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif =3D=3D=3D Mark Millard markmi@dsl-only.net