Re: C++ in jemalloc
Re: the risk of dependencies on the C++ runtime. (apologies Konstantin, your email got trapped in a spam filter; "It is in violation of Google's recommended email sender guidelines", according to GMail). Avoiding C++ runtime dependencies is fairly straightforward in practice (e.g. a program that doesn't use *use* thread-local objects with destructors won't link against cxa_thread_atexit; similarly, -fno-exceptions and -fno-rtti and their equivalents are widely available). It's impossible of course to guarantee that FreeBSD won't ever want to switch to a (not-yet-written, afaik) compiler + ABI combo that doesn't admit a runtime-less C++, but that seems unlikely (and, if it were to happen, it would take enough years of notice and effort that porting the allocator back to C would be a small relative cost). We also test bootstrapping behavior against the libcs that we care about, so that we get some relatively good signal that everything will integrate correctly on a per-jemalloc-commit basis (we don't try to test against FreeBSD head, but I don't think that's necessarily a feasible strategy). I'm sympathetic to the costs of the added compiler required for those building libc, but weighing it against the ongoing maintenance drag on our end, it seems like a no-brainer (especially when we already come with dependencies outside of just the compiler and base build system). - David On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
[I should have checked for 3 digit numerals in r notation.] On 2017-Oct-7, at 11:36 PM, Mark Millard wrote: > With a fresh day after sleep and some pondering > I finally am thinking straight for where things > are in files for C++ scratch register usage and > such: > > It is libgcc_s.so.1 that has all the extra use of > scratch registers for C++ exception handling --and > lots of other special stuff as well. > > This note is just about overall counts of example > usages in devel/powerpc64-gcc vs. clang processing > the same libgcc_s source. it gives a clue about > what coverage is going to be necessary. > > > So the compare/contrast is of: > (shown as seen in my context) > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > vs. > # dwarfdump -v -v -F /lib/libgcc_s.so.1 > > (That last being from a clang-based buildworld and the > first being from a devel/powerpc64-xtoolchain-gcc > material based buildworld.) > > Using r2 through r6 as initial examples: > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 432683 18432 > > vs. > > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\" | wc > 0 0 0 > > That is an example of missing information from clang. > > For powerpc64-gcc it is interesting that. . . > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 232063 14308 > > but: > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 272571 17800 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 272571 17800 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 272571 17800 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 272571 17800 > > and: > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 0 0 0 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 0 0 0 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "\" | wc > 0 0 0 > > Looks like r2 might sometimes be a scratch or otherwise > special register during C++ exception handling --but not > everyplace that r3-r6 are. > > There are lots of other special r names with numerals > beyond that in the name r31 (powerpc64-gcc context): > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r3[2-9]" | wc > 0 0 0 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r4[0-9]" | wc > 643248 22391 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r5[0-9]" | wc > 1243548 24183 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r6[0-9]" | wc > 3446978 49690 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r7[0-9]" | wc > 462314 16176 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r8[0-9]" | wc > 0 0 0 > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | grep "r9[0-9]" | wc > 0 0 0 > > Overall for > 31: > > # dwarfdump -v -v -F > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 > | egrep "(r3[2-9]|r[4-9][0-9])" | wc > 5057867 55379 > > > By contrast from clang for > 31: > > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc > 2543110 21110 > > with the more detailed split out being: > > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r3[2-9]" | wc > 0 0 0 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r4[0-9]" | wc > 25 7755190 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r5[0-9]" | wc > 55 9856265 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r6[0-9]" | wc > 1522396 17011 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r7[0-9]" | wc > 24 8285747 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r8
Re: C++ in jemalloc
With a fresh day after sleep and some pondering I finally am thinking straight for where things are in files for C++ scratch register usage and such: It is libgcc_s.so.1 that has all the extra use of scratch registers for C++ exception handling --and lots of other special stuff as well. This note is just about overall counts of example usages in devel/powerpc64-gcc vs. clang processing the same libgcc_s source. it gives a clue about what coverage is going to be necessary. So the compare/contrast is of: (shown as seen in my context) # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 vs. # dwarfdump -v -v -F /lib/libgcc_s.so.1 (That last being from a clang-based buildworld and the first being from a devel/powerpc64-xtoolchain-gcc material based buildworld.) Using r2 through r6 as initial examples: # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 432683 18432 vs. # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\" | wc 0 0 0 That is an example of missing information from clang. For powerpc64-gcc it is interesting that. . . # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 232063 14308 but: # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 272571 17800 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 272571 17800 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 272571 17800 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 272571 17800 and: # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 0 0 0 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 0 0 0 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\" | wc 0 0 0 Looks like r2 might sometimes be a scratch or otherwise special register during C++ exception handling --but not everyplace that r3-r6 are. There are lots of other special r names with numerals beyond that in the name r31 (powerpc64-gcc context): # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r3[2-9]" | wc 0 0 0 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r4[0-9]" | wc 643248 22391 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r5[0-9]" | wc 1243548 24183 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r6[0-9]" | wc 3446978 49690 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r7[0-9]" | wc 462314 16176 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r8[0-9]" | wc 0 0 0 # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "r9[0-9]" | wc 0 0 0 Overall for > 31: # dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc 5057867 55379 By contrast from clang for > 31: # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc 2543110 21110 with the more detailed split out being: # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r3[2-9]" | wc 0 0 0 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r4[0-9]" | wc 25 7755190 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r5[0-9]" | wc 55 9856265 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r6[0-9]" | wc 1522396 17011 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r7[0-9]" | wc 24 8285747 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r8[0-9]" | wc 0 0 0 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r9[0-9]" | wc 20 7405135 WARNING: That last means that clang is using some r's that devel/powerpc64-gcc is not. Is libgcc_s ready to deal with those extras that are in the 90s? Is this an ABI difference between clang (as configured) and powerpc64-gcc (as configured)? Is th
Re: C++ in jemalloc
It turns out that /usr/local/bin/gdb crashing for the clang-built powerpc64 world is again due to C++ exceptions being thrown, this time in gdb80 itself. This helps explain why for clang-based buildworld experiments /usr/libexec/gdb is a better alternative currently for the powerpc families. Again the _Unwind_SetGR use in __gxx_personality_v0 fails: # ls -lT /usr/local/bin/gdb* lrwxr-xr-x 1 root wheel 5 Sep 29 15:25:15 2017 /usr/local/bin/gdb -> gdb80 -r-xr-xr-x 1 root wheel 97577168 Sep 29 15:25:15 2017 /usr/local/bin/gdb80 lrwxr-xr-x 1 root wheel 5 Sep 29 15:25:15 2017 /usr/local/bin/gdbtui80 -> gdb80 # ldd /usr/local/bin/gdb80 /usr/local/bin/gdb80: libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0x50e8) libncurses.so.8 => /lib/libncurses.so.8 (0x50ef7000) libkvm.so.7 => /lib/libkvm.so.7 (0x50f61000) libutil.so.9 => /lib/libutil.so.9 (0x50f83000) libm.so.5 => /lib/libm.so.5 (0x50fad000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x50fe5000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x5102a000) libc++.so.1 => /usr/lib/libc++.so.1 (0x5105d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x5118a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x511b1000) libc.so.7 => /lib/libc.so.7 (0x511d6000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x51528000) libelf.so.2 => /lib/libelf.so.2 (0x515ac000) libthr.so.3 => /lib/libthr.so.3 (0x515da000) # /usr/libexec/gdb /usr/local/bin/gdb80 /var/crash/gdb80.14502.core . . . Core was generated by `/usr/local/bin/gdb /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/s'. Program terminated with signal 11, Segmentation fault. . . . (gdb) bt #0 0x511b5c20 in _Unwind_SetGR (context=, index=, val=1374378080) at unwind-dw2-fde.h:162 #1 0x5119f194 in __gxx_personality_v0 (version=, actions=, exceptionClass=, exceptionObject=0x51eb5860, context=0xb420) at /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x511b6a60 in _Unwind_RaiseException_Phase2 (exc=0x51eb5860, context=0xb420) at unwind.inc:66 #3 0x511b6548 in _Unwind_RaiseException (exc=) at unwind.inc:135 #4 0x5119e4f4 in __cxa_throw (thrown_exception=, tinfo=, dest=) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x102be040 in throw_exception () at common-exceptions.c:303 #6 0x102be1dc in throw_it (reason=1374378080, error=4294947872, fmt=, ap=) at common-exceptions.c:373 #7 0x102be0a4 in throw_verror (error=, fmt=, ap=) at common-exceptions.c:379 #8 0x102be258 in throw_error (error=GDB_NO_ERROR, fmt=0x18 ) at common-exceptions.c:394 #9 0x10279bf8 in call_site_for_pc (gdbarch=, pc=) at block.c:241 #10 0x102e93e0 in call_site_find_chain (gdbarch=, caller_pc=, callee_pc=) at dwarf2loc.c:1057 #11 0x102e4800 in dwarf2_tailcall_sniffer_first (this_frame=0x51eb5808, tailcall_cachep=0x51eb5860, entry_cfa_sp_offsetp=0xb420) at dwarf2-frame-tailcall.c:387 #12 0x102e32b8 in ._ZL26dwarf2_frame_prev_registerP10frame_infoPPvi () at __split_buffer:311 #13 0x10340464 in frame_unwind_register_value (frame=, regnum=) at frame.c:1200 #14 0x10340148 in frame_register_unwind (frame=0x0, regnum=, optimizedp=0x51eb5860, unavailablep=0x51eb5808, lvalp=0x514077a0, addrp=0x51eb5808, realnump=0x6, bufferp=0xb420 "") at frame.c:1102 #15 0x10341ddc in get_prev_frame_always_1 (this_frame=0xb420) at frame.c:1840 #16 0x1033e878 in get_prev_frame_always (this_frame=0xb420) at frame.c:2092 #17 0x1033e110 in get_prev_frame (this_frame=0xb420) at frame.c:2345 #18 0x10419464 in backtrace_command (arg=, from_tty=1374378080) at stack.c:1830 #19 0x101e3654 in do_cfunc (c=, args=0x0, from_tty=24) at cli/cli-decode.c:106 #20 0x101e67b0 in cmd_func (cmd=0x0, args=0x18 , from_tty=) at cli/cli-decode.c:1896 #21 0x1046497c in execute_command (p=, from_tty=1374377992) at top.c:674 #22 0x1032e398 in command_handler (command=0xb420 "") at event-top.c:590 #23 0x1032e788 in command_line_handler (rl=) at event-top.c:780 #24 0x1032dc54 in gdb_rl_callback_handler (rl=) at event-top.c:213 #25 0x50ec5950 in rl_callback_read_char () at ../callback.c:283 #26 0x1032f560 in gdb_rl_callback_read_char_wrapper_noexcept () at event-top.c:175 #27 0x1032d84c in gdb_rl_callback_read_char_wrapper (client_data=) at event-top.c:192 #28 0x1032e14c in stdin_event_handler (error=, client_data=0xb420) at event-top.c:518 #29 0x1032d690 in handle_file_event (file_ptr=0xb420, ready_mask=1374378080) at event-loop.c:733 #30 0x1032c830 in gdb_wait_for_event (block=) at common-exceptions.h:220 #31 0x1032c2c4 in gdb_do_one_event () at event-
Re: C++ in jemalloc
On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote: > Answers inline. > > On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote: >> Just a short top-post as this does not fit well with the >> other material: >> >> I believe Roman only built his example program >> with clang, not the world that the program was >> being run under. > > I used a machine with gcc built world and compiled the test program using > > clang -stdlib=libstdc++ There is (and was) no libstdc++ in my context. So I'd have to build a clang based world that had it first. Note: Nothing that I've been saying indicates if what you found earlier was a separate issue as far as I know. >> The gcc 4.2.1 based code that is analogous to >> __cxa_begin_catch (scratch register initialization) >> in a clang based build world has the scratch >> register CFI material and the same clang produced >> a.out file works fine under such a system (simply >> copied over and run). >> >> And that is why Roman's context did not SIGSEGV but >> mine did: I used clang for the buildworld for >> the world that was being used and so >> __cxa_begin_catch was missing CFI information in >> my build. >> >> In fact the a.out built by gcc 4.2.1 fails under >> the clang based buildworld with the bad >> __cxa_begin_catch . >> >> The only thing that matters is the system library >> code involved, not which a.out (from which compiler). > > Ah. I see... Is it possible to isolate a small example > that shows the missing CFI info from clang so that I can > try to fix it without having to build world etc. ? > > It should be reasonably simple. The following (using lang/gcc7 as an example) in a clang-built world also gets a SIGSEGV: # env C_INCLUDE_PATH=/usr/include CPLUS_INCLUDE_PATH=/usr/include/c++/v1 /usr/local/bin/g++7 -std=c++11 -nostdinc++ -L/usr/lib -g -O2 exception_test.cpp # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x5004f000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x5017c000) libm.so.5 => /lib/libm.so.5 (0x501a3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x501db000) libc.so.7 => /lib/libc.so.7 (0x5020) # ./a.out Segmentation fault (core dumped) #0 0x501dfc20 in _Unwind_SetGR (context=, index=, val=1342451808) at unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x501dfc20 in _Unwind_SetGR (context=, index=, val=1342451808) at unwind-dw2-fde.h:162 #1 0x50191194 in __gxx_personality_v0 (version=, actions=, exceptionClass=, exceptionObject=0x50043060, context=0xcc80) at /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x501e0a60 in _Unwind_RaiseException_Phase2 (exc=0x50043060, context=0xcc80) at unwind.inc:66 #3 0x501e0548 in _Unwind_RaiseException (exc=) at unwind.inc:135 #4 0x501904f4 in __cxa_throw (thrown_exception=, tinfo=, dest=) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x1898 in ?? () compared to system-clang's: #0 0x50530c20 in _Unwind_SetGR (context=, index=, val=1342447712) at unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x50530c20 in _Unwind_SetGR (context=, index=, val=1342447712) at unwind-dw2-fde.h:162 #1 0x50190194 in __gxx_personality_v0 (version=, actions=, exceptionClass=, exceptionObject=0x50042060, context=0xcc60) at /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x50531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060, context=0xcc60) at unwind.inc:66 #3 0x50531548 in _Unwind_RaiseException (exc=) at unwind.inc:135 #4 0x5018f4f4 in __cxa_throw (thrown_exception=, tinfo=, dest=) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x1d74 in main () at exception_test.cpp:5 #6 0x1ae8 in _start (argc=1342447624, argv=0x50042060, env=0xcc60, obj=, cleanup=, ps_strings=) at /usr/src/lib/csu/powerpc64/crt1.c:94 #7 0x50017b70 in .text () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Current language: auto; currently minimal The code generation involved is tied to (driven by) the use of builtins, not just normal C/C++ code. Inlining is also mixed in. There could be more wrong than I've noticed. At some point comparing the dwarfdump output for gcc and clang for the same "interesting" source(s) being compiled would be appropriate, looking for mismatches that are not equivalent. (Unfortunately equivalence need not be a trivial judgment to make since CFI is a programming language of its own and the code being described is not identical, possibly inlined differently even.) So I'm building based on devel/powerpc64-xtoolchain-gcc using WITH_LIBCPLUSPLUS= to compare against. (I've not done a powerpc64-xtoolchain-gcc based build in a long time. Hopefully it still builds to completion.) It is far enough along now to have built a libcxxrt.so.1 so. . . But I need sleep. (It is well after 8am here.) All I'm managing to do is confuse myself at
Re: C++ in jemalloc
Answers inline. On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote: > Just a short top-post as this does not fit well with the > other material: > > I believe Roman only built his example program > with clang, not the world that the program was > being run under. I used a machine with gcc built world and compiled the test program using clang -stdlib=libstdc++ > The gcc 4.2.1 based code that is analogous to > __cxa_begin_catch (scratch register initialization) > in a clang based build world has the scratch > register CFI material and the same clang produced > a.out file works fine under such a system (simply > copied over and run). > > And that is why Roman's context did not SIGSEGV but > mine did: I used clang for the buildworld for > the world that was being used and so > __cxa_begin_catch was missing CFI information in > my build. > > In fact the a.out built by gcc 4.2.1 fails under > the clang based buildworld with the bad > __cxa_begin_catch . > > The only thing that matters is the system library > code involved, not which a.out (from which compiler). Ah. I see... Is it possible to isolate a small example that shows the missing CFI info from clang so that I can try to fix it without having to build world etc. ? It should be reasonably simple. > On 2017-Oct-7, at 2:54 AM, Mark Millard wrote: > > [The last part of my note has a dumb mistake, not > that it messes up the other evidence. I should have > dwarfdump'd not a.out but the code in the libraries, > such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I > made the same mistake initially back when Roman and > I were dealing with this long ago. Correcting it > again. . .] > > On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > > > [I'm separately listing backtrace information and related > > information from one of core dumps and going back through > > the details to see if they seem to be as they were back > > then. Read only if you care. It does look the same as I > > found back then if I remember right. I reach the same > > conclusion I reached back then anyway. I give evidence > > in the below.] > > > > On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > > > >> [I'm adding examples with output from clang -v since it explicitly shows > >> the path used for ld and such.] > >> > >> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: > >> > >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: > >>> > Just to clarify my not agreeing with Mark regarding EH on ppc64. > > Last time I tried to fix ppc64 exceptions handling as generated by clang > it turned out that simply using gnu ld from ports fixes the issue. > > For details see: > https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html > >>> > >>> Unfortunately my experiments failed to confirm this. Repeating > >>> them now under head -r324071 and ports -r450478 : > >>> > >>> # more exception_test.cpp > >>> #include > >>> > >>> int main(void) > >>> { > >>> try { throw std::exception(); } > >>> catch (std::exception& e) {} > >>> return 0; > >>> } > >>> > >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 > >>> exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >>> > >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g > >>> exception_test.cpp > >>> > >>> # ./a.out > >>> Segmentation fault (core dumped) > >> > >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g > >> exception_test.cpp > >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM > >> 5.0.0svn) > >> Target: powerpc64-unknown-freebsd12.0 > >> Thread model: posix > >> InstalledDir: /usr/bin > >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj > >> -mrelax-all -disable-free -main-file-name exception_test.cpp > >> -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim > >> -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v > >> -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 > >> -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem > >> /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir > >> /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char > >> -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions > >> -fdiagnostics-show-option -fcolor-diagnostics -o > >> /tmp/exception_test-ba79a4.o -x c++ exception_test.cpp > >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target > >> powerpc64-unknown-freebsd12.0 > >> #include "..." search starts here: > >> #include <...> search starts here: > >> /usr/include/c++/v1 > >> /usr/lib/clang/5.0.0/include > >> /usr/include > >> End of search list. > >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker > >> /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o > >> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib > >> /tmp/exception_
Re: C++ in jemalloc
Just to clarify my not agreeing with Mark regarding EH on ppc64. Last time I tried to fix ppc64 exceptions handling as generated by clang it turned out that simply using gnu ld from ports fixes the issue. For details see: https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html Roman On Fri, Oct 06, 2017 at 09:28:37AM -0700, Mark Millard wrote: > On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote: > > > Hi Mark, > > > > On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote: > >> 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=powerpc64 and TARGET_ARCH=powerpc : > >> > >> 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. > > > > Do you see this problem using libstdc++, et al, from base gcc 4.2.1? > > Or using libc++? > > gcc 4.2.1 buildkernel buildworld work fine for anything that I've > tried. They are libstdc++ based. > > I've not tried clang with libstdc++, just libc++. (Note: clang 3.8, > 3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals > tend to be from the earlier time frame. Many of my submittals for > other types of issues have been addressed. ) > > But my llvm bugzilla submittals for C++ exceptions indicate > errors/incompletenesses in the DW_CFA_ generation, such as > for scratch register handling. (Warning: I've not been through > the details in some time so this is from a vague memory.) 26844 > and 26856 are the relevant ones if I remember right. 31590 might > be relevant depending on what linunwind is to be used. > > Be warned that I do not believe Roman Divacky agrees with my > interpretation and I'd never studied the exception handling > techniques prior to these investigations. Still I think that > I was correct about there being problems in the DW_CFA_ > sequences generated. > > For a separate issue llvm 31716 is relevant for .plt and the > function descriptor layout. I use Roman Divacky's patch listing in > Comment 1. Included below as well. > > The llvm patches that I have are both from Roman as I remember: > > Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > === > --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > (revision 324071) > +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > (working copy) > @@ -1178,7 +1178,7 @@ >// For SVR4, don't emit a move for the CR spill slot if we haven't >// spilled CRs. >if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4) > - && !MustSaveCR) > + && (!MustSaveCR && isPPC64)) > continue; > >// For 64-bit SVR4 when we have spilled CRs, the spill location > Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > === > --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision 324071) > +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy) > @@ -60,7 +60,8 @@ > static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; } > > PPC64::PPC64() { > - PltRel = GotRel = R_PPC64_GLOB_DAT; > + GotRel = R_PPC64_GLOB_DAT; > + PltRel = R_PPC64_JMP_SLOT; >RelativeRel = R_PPC64_RELATIVE; >GotEntrySize = 8; >GotPltEntrySize = 8; > > > > > I don't have the time right now to look into it, but if no one else is > > able to in the next couple months I'll try to make the time when > > higher priorities are done. > > Are you familiar with what the DQ_CFA_ sequences should > be like given the powerpc scratch register usage and the > like? > > >> 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=powerpc > >> kernel. (I was able to back in clang 4 days --but the > >> resulta
Re: C++ in jemalloc
Just a short top-post as this does not fit well with the other material: I believe Roman only built his example program with clang, not the world that the program was being run under. The gcc 4.2.1 based code that is analogous to __cxa_begin_catch (scratch register initialization) in a clang based build world has the scratch register CFI material and the same clang produced a.out file works fine under such a system (simply copied over and run). And that is why Roman's context did not SIGSEGV but mine did: I used clang for the buildworld for the world that was being used and so __cxa_begin_catch was missing CFI information in my build. In fact the a.out built by gcc 4.2.1 fails under the clang based buildworld with the bad __cxa_begin_catch . The only thing that matters is the system library code involved, not which a.out (from which compiler). On 2017-Oct-7, at 2:54 AM, Mark Millard wrote: [The last part of my note has a dumb mistake, not that it messes up the other evidence. I should have dwarfdump'd not a.out but the code in the libraries, such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I made the same mistake initially back when Roman and I were dealing with this long ago. Correcting it again. . .] On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > [I'm separately listing backtrace information and related > information from one of core dumps and going back through > the details to see if they seem to be as they were back > then. Read only if you care. It does look the same as I > found back then if I remember right. I reach the same > conclusion I reached back then anyway. I give evidence > in the below.] > > On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > >> [I'm adding examples with output from clang -v since it explicitly shows >> the path used for ld and such.] >> >> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: >> >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: >>> Just to clarify my not agreeing with Mark regarding EH on ppc64. Last time I tried to fix ppc64 exceptions handling as generated by clang it turned out that simply using gnu ld from ports fixes the issue. For details see: https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html >>> >>> Unfortunately my experiments failed to confirm this. Repeating >>> them now under head -r324071 and ports -r450478 : >>> >>> # more exception_test.cpp >>> #include >>> >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 >>> exception_test.cpp >>> >>> # ./a.out >>> Segmentation fault (core dumped) >>> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g >>> exception_test.cpp >>> >>> # ./a.out >>> Segmentation fault (core dumped) >> >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g >> exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM >> 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj >> -mrelax-all -disable-free -main-file-name exception_test.cpp >> -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim >> -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v >> -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 >> -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem >> /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir >> /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char >> -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions >> -fdiagnostics-show-option -fcolor-diagnostics -o >> /tmp/exception_test-ba79a4.o -x c++ exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target >> powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker >> /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o >> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-ba79a4.o >> -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed >> -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >> >> # ./a.out >> Segmentation fault (core dumped) >> >> >>> # ls -lt /usr/local/powerpc64-freebsd/bin >>> total 56704 >>> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> >>> ../../bin/powerpc64-freebsd-size >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >>> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >>> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >>> -r-xr-xr-x 2
Re: C++ in jemalloc
[The last part of my note has a dumb mistake, not that it messes up the other evidence. I should have dwarfdump'd not a.out but the code in the libraries, such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I made the same mistake initially back when Roman and I were dealing with this long ago. Correcting it again. . .] On 2017-Oct-7, at 2:18 AM, Mark Millard wrote: > [I'm separately listing backtrace information and related > information from one of core dumps and going back through > the details to see if they seem to be as they were back > then. Read only if you care. It does look the same as I > found back then if I remember right. I reach the same > conclusion I reached back then anyway. I give evidence > in the below.] > > On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > >> [I'm adding examples with output from clang -v since it explicitly shows >> the path used for ld and such.] >> >> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: >> >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: >>> Just to clarify my not agreeing with Mark regarding EH on ppc64. Last time I tried to fix ppc64 exceptions handling as generated by clang it turned out that simply using gnu ld from ports fixes the issue. For details see: https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html >>> >>> Unfortunately my experiments failed to confirm this. Repeating >>> them now under head -r324071 and ports -r450478 : >>> >>> # more exception_test.cpp >>> #include >>> >>> int main(void) >>> { >>> try { throw std::exception(); } >>> catch (std::exception& e) {} >>> return 0; >>> } >>> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 >>> exception_test.cpp >>> >>> # ./a.out >>> Segmentation fault (core dumped) >>> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g >>> exception_test.cpp >>> >>> # ./a.out >>> Segmentation fault (core dumped) >> >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g >> exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM >> 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj >> -mrelax-all -disable-free -main-file-name exception_test.cpp >> -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim >> -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v >> -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 >> -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem >> /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir >> /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char >> -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions >> -fdiagnostics-show-option -fcolor-diagnostics -o >> /tmp/exception_test-ba79a4.o -x c++ exception_test.cpp >> clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target >> powerpc64-unknown-freebsd12.0 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include/c++/v1 >> /usr/lib/clang/5.0.0/include >> /usr/include >> End of search list. >> "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker >> /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o >> /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-ba79a4.o >> -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed >> -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o >> >> # ./a.out >> Segmentation fault (core dumped) >> >> >>> # ls -lt /usr/local/powerpc64-freebsd/bin >>> total 56704 >>> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> >>> ../../bin/powerpc64-freebsd-size >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >>> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >>> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >>> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >>> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm >>> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf >>> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy >>> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib >>> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar >>> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >>> >>> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g >>> -O2 exception_test.cpp >>> >>> # ./a.out >>> Segmentation fault (core dumped) >> >> # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g >> -O2 exception_test.cpp >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM >> 5.0.0svn) >> Target: powerpc64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj >> -disable-free -main-file-name exception_
Re: C++ in jemalloc
[I'm separately listing backtrace information and related information from one of core dumps and going back through the details to see if they seem to be as they were back then. Read only if you care. It does look the same as I found back then if I remember right. I reach the same conclusion I reached back then anyway. I give evidence in the below.] On 2017-Oct-7, at 1:10 AM, Mark Millard wrote: > [I'm adding examples with output from clang -v since it explicitly shows > the path used for ld and such.] > > On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: > >> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: >> >>> Just to clarify my not agreeing with Mark regarding EH on ppc64. >>> >>> Last time I tried to fix ppc64 exceptions handling as generated by clang >>> it turned out that simply using gnu ld from ports fixes the issue. >>> >>> For details see: >>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html >> >> Unfortunately my experiments failed to confirm this. Repeating >> them now under head -r324071 and ports -r450478 : >> >> # more exception_test.cpp >> #include >> >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >> >> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 >> exception_test.cpp >> >> # ./a.out >> Segmentation fault (core dumped) >> >> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g >> exception_test.cpp >> >> # ./a.out >> Segmentation fault (core dumped) > > # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g > exception_test.cpp > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM > 5.0.0svn) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj > -mrelax-all -disable-free -main-file-name exception_test.cpp > -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim > -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v > -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 > -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem > /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir > /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char > -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o > -x c++ exception_test.cpp > clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target > powerpc64-unknown-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/include/c++/v1 > /usr/lib/clang/5.0.0/include > /usr/include > End of search list. > "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker > /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o > /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-ba79a4.o > -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed > -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o > > # ./a.out > Segmentation fault (core dumped) > > >> # ls -lt /usr/local/powerpc64-freebsd/bin >> total 56704 >> lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> >> ../../bin/powerpc64-freebsd-size >> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld >> -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd >> -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as >> -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip >> -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm >> -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf >> -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy >> -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib >> -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar >> -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump >> >> # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 >> exception_test.cpp >> >> # ./a.out >> Segmentation fault (core dumped) > > # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g > -O2 exception_test.cpp > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM > 5.0.0svn) > Target: powerpc64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj > -disable-free -main-file-name exception_test.cpp -mrelocation-model pic > -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose > -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v > -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 > -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem > /usr/include/c++/v1 -O2 -std=c++14 -fdeprecated-macro -fdebug-compilation-dir > /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char > -fobjc-runtime=gnustep -fcxx-
Re: C++ in jemalloc
[I'm adding examples with output from clang -v since it explicitly shows the path used for ld and such.] On 2017-Oct-7, at 12:58 AM, Mark Millard wrote: > On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: > >> Just to clarify my not agreeing with Mark regarding EH on ppc64. >> >> Last time I tried to fix ppc64 exceptions handling as generated by clang >> it turned out that simply using gnu ld from ports fixes the issue. >> >> For details see: >> https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html > > Unfortunately my experiments failed to confirm this. Repeating > them now under head -r324071 and ports -r450478 : > > # more exception_test.cpp > #include > > int main(void) > { >try { throw std::exception(); } >catch (std::exception& e) {} >return 0; > } > > # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 > exception_test.cpp > > # ./a.out > Segmentation fault (core dumped) > > # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g exception_test.cpp > > # ./a.out > Segmentation fault (core dumped) # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g exception_test.cpp FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-ba79a4.o -x c++ exception_test.cpp clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/powerpc64-freebsd/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-ba79a4.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o # ./a.out Segmentation fault (core dumped) > # ls -lt /usr/local/powerpc64-freebsd/bin > total 56704 > lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> > ../../bin/powerpc64-freebsd-size > -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld > -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd > -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as > -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip > -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm > -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf > -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy > -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib > -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar > -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump > > # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 > exception_test.cpp > > # ./a.out > Segmentation fault (core dumped) # clang++ -v -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 exception_test.cpp FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Target: powerpc64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj -disable-free -main-file-name exception_test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2 -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 -O2 -std=c++14 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/exception_test-3ebf72.o -x c++ exception_test.cpp clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target powerpc64-unknown-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/powerpc64-portbld-freebsd12.0/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib
Re: C++ in jemalloc
On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote: > Just to clarify my not agreeing with Mark regarding EH on ppc64. > > Last time I tried to fix ppc64 exceptions handling as generated by clang > it turned out that simply using gnu ld from ports fixes the issue. > > For details see: > https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html Unfortunately my experiments failed to confirm this. Repeating them now under head -r324071 and ports -r450478 : # more exception_test.cpp #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2 exception_test.cpp # ./a.out Segmentation fault (core dumped) # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g exception_test.cpp # ./a.out Segmentation fault (core dumped) # ls -lt /usr/local/powerpc64-freebsd/bin total 56704 lrwxr-xr-x 1 root wheel 32 Jul 2 19:27 size -> ../../bin/powerpc64-freebsd-size -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld -r-xr-xr-x 4 root wheel 7072791 Jul 2 19:27 ld.bfd -r-xr-xr-x 2 root wheel 6881822 Jul 2 19:27 as -r-xr-xr-x 2 root wheel 6128889 Jul 2 19:27 strip -r-xr-xr-x 2 root wheel 5253417 Jul 2 19:27 nm -r-xr-xr-x 2 root wheel 1284139 Jul 2 19:27 readelf -r-xr-xr-x 2 root wheel 6128882 Jul 2 19:27 objcopy -r-xr-xr-x 2 root wheel 5384166 Jul 2 19:27 ranlib -r-xr-xr-x 2 root wheel 5384159 Jul 2 19:27 ar -r-xr-xr-x 2 root wheel 6914775 Jul 2 19:27 objdump # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++14 -g -O2 exception_test.cpp # ./a.out Segmentation fault (core dumped) # clang++ -B /usr/local/powerpc64-portbld-freebsd12.0/bin/ -std=c++11 -g exception_test.cpp # ./a.out Segmentation fault (core dumped) # ls -lt /usr/local/powerpc64-portbld-freebsd12.0/bin/ total 363584 -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld -r-xr-xr-x 4 root wheel 59993201 Jul 2 23:44 ld.bfd -r-xr-xr-x 2 root wheel 29843304 Jul 2 23:44 as -r-xr-xr-x 2 root wheel 29046519 Jul 2 23:44 strip -r-xr-xr-x 2 root wheel 28207257 Jul 2 23:44 nm -r-xr-xr-x 2 root wheel 1178483 Jul 2 23:44 readelf -r-xr-xr-x 1 root wheel 28329180 Jul 2 23:44 dlltool -r-xr-xr-x 2 root wheel 29046512 Jul 2 23:44 objcopy -r-xr-xr-x 2 root wheel 28334599 Jul 2 23:44 ranlib -r-xr-xr-x 2 root wheel 28334592 Jul 2 23:44 ar -r-xr-xr-x 2 root wheel 49540244 Jul 2 23:44 objdump === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On 2017-Oct-6, at 9:58 AM, Conrad Meyer wrote: > On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: >> It isn't about "a broken port". All C++ code is broken if exceptions >> don't work. That means devd is broken. Not to mention clang itself. >> It may be that neither of those relies on exceptions for routine >> operation and uses them only for error handling, and errors mostly >> don't happen. There is plenty of C++ code in the world where >> exceptions are used in non-fatal-error cases and where the applications >> just don't work at all without them. > > Then use G++ for C++ on those second-tier architectures. We've got a > working C++ toolchain. g++'s toolchain (such as via devel/powerpc64-xtoolchain-gcc ) has its own problems: A) For targeting powerpc64 it fails to build a working lib32. (This may well be better than clang's status overall.) B) For targeting powerpc (32-bit): what toolchain? === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. Then use G++ for C++ on those second-tier architectures. We've got a working C++ toolchain. Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > wrote: > > > > 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. > I don't think that is a major roadblock; a broken port is a broken > port. Kyua is a relatively unimportant one for most users. In this > particular case, maybe kyua (a leaf binary) could be built with GCC > instead of Clang on any platform with broken C++ exceptions. > > Best, > Conrad It isn't about "a broken port". All C++ code is broken if exceptions don't work. That means devd is broken. Not to mention clang itself. It may be that neither of those relies on exceptions for routine operation and uses them only for error handling, and errors mostly don't happen. There is plenty of C++ code in the world where exceptions are used in non-fatal-error cases and where the applications just don't work at all without them. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote: > Hi Mark, > > On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote: >> 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=powerpc64 and TARGET_ARCH=powerpc : >> >> 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. > > Do you see this problem using libstdc++, et al, from base gcc 4.2.1? > Or using libc++? gcc 4.2.1 buildkernel buildworld work fine for anything that I've tried. They are libstdc++ based. I've not tried clang with libstdc++, just libc++. (Note: clang 3.8, 3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals tend to be from the earlier time frame. Many of my submittals for other types of issues have been addressed. ) But my llvm bugzilla submittals for C++ exceptions indicate errors/incompletenesses in the DW_CFA_ generation, such as for scratch register handling. (Warning: I've not been through the details in some time so this is from a vague memory.) 26844 and 26856 are the relevant ones if I remember right. 31590 might be relevant depending on what linunwind is to be used. Be warned that I do not believe Roman Divacky agrees with my interpretation and I'd never studied the exception handling techniques prior to these investigations. Still I think that I was correct about there being problems in the DW_CFA_ sequences generated. For a separate issue llvm 31716 is relevant for .plt and the function descriptor layout. I use Roman Divacky's patch listing in Comment 1. Included below as well. The llvm patches that I have are both from Roman as I remember: Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp === --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (revision 324071) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp (working copy) @@ -1178,7 +1178,7 @@ // For SVR4, don't emit a move for the CR spill slot if we haven't // spilled CRs. if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4) - && !MustSaveCR) + && (!MustSaveCR && isPPC64)) continue; // For 64-bit SVR4 when we have spilled CRs, the spill location Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp === --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision 324071) +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy) @@ -60,7 +60,8 @@ static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; } PPC64::PPC64() { - PltRel = GotRel = R_PPC64_GLOB_DAT; + GotRel = R_PPC64_GLOB_DAT; + PltRel = R_PPC64_JMP_SLOT; RelativeRel = R_PPC64_RELATIVE; GotEntrySize = 8; GotPltEntrySize = 8; > I don't have the time right now to look into it, but if no one else is > able to in the next couple months I'll try to make the time when > higher priorities are done. Are you familiar with what the DQ_CFA_ sequences should be like given the powerpc scratch register usage and the like? >> 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=powerpc >> 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 >> in use in both cases. > > What problem(s) do you see with this? If they're just compile time > failures they can be fixed pretty readily. I submitted FreeBSD bugzilla 221107 for the: R_PPC_PLTREL24 reloc against local symbol failures. This was using system binutils. In a parallel builds it is a race between agp.* vs. aha.* reporting this and stopping the build. >> I do build the kernel and
Re: C++ in jemalloc
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote: > On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote: > > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard > > wrote: > > > > > > 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. > > I don't think that is a major roadblock; a broken port is a broken > > port. Kyua is a relatively unimportant one for most users. In this > > particular case, maybe kyua (a leaf binary) could be built with GCC > > instead of Clang on any platform with broken C++ exceptions. > > > > Best, > > Conrad > > It isn't about "a broken port". All C++ code is broken if exceptions > don't work. That means devd is broken. Not to mention clang itself. > It may be that neither of those relies on exceptions for routine > operation and uses them only for error handling, and errors mostly > don't happen. There is plenty of C++ code in the world where > exceptions are used in non-fatal-error cases and where the applications > just don't work at all without them. > I'm with Ian: Broken C++ exceptions means a broken C++ compiler. It's best to think of it like the tertiary operator being wonky in 'C'... Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote: > 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. I don't think that is a major roadblock; a broken port is a broken port. Kyua is a relatively unimportant one for most users. In this particular case, maybe kyua (a leaf binary) could be built with GCC instead of Clang on any platform with broken C++ exceptions. Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
Hi Mark, On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote: > 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=powerpc64 and TARGET_ARCH=powerpc : > > 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. Do you see this problem using libstdc++, et al, from base gcc 4.2.1? Or using libc++? I don't have the time right now to look into it, but if no one else is able to in the next couple months I'll try to make the time when higher priorities are done. > > 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=powerpc > 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 > in use in both cases. What problem(s) do you see with this? If they're just compile time failures they can be fixed pretty readily. > > I do build the kernel and world for > TARGET_ARCH=powerpc64 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. There's documentation floating around (on the wiki maybe?) for doing this. I won't check now, but it's not difficult (not trivial, but not difficult). With the proposal to eliminate gcc 4.2.1 from our tree by the end of the year, we need to get everything in place to make a seamless transition, whether it be to external toolchain or to finish up clang for powerpc. I really hope we can finish up clang. Please continue to file bugs with as much detail as necessary to track down and fix the problems--both in FreeBSD and upstream LLVM. - Justin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. Note that these are just usermode utilities, which implementation language is not too important. If we considered ghc or rustc to be acceptable dependency for utilities, then they could be implemented in Haskell or Rust as well. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. I wonder how can you guarantee that for current and future compilers without having the standard saying and compiler facilities to ensure that. See below. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. On Thu, Oct 05, 2017 at 04:50:32PM -0700, David Goldblatt wrote: > We can avoid it in the short term without a ton of pain. In the long run it > would be nice to have, but I wouldn't want to tie our release schedule to > FreeBSD's too tightly (our CI is improving to the point where the tip of > the dev branch gets tested about as well as releases would be, so we're > trying to de-emphasize release vs. non-release versions). Do you have a > sense of when the situation might change (if only so I know when to check > back)? > > Thanks for the replies on this, they've been super helpful. I do not think so. You are talking about importing C++ code into libc. Libc _implements_ C runtime, which is a dependency of any C++ runtime. That is, we cannot allow C++ runtime to be dragged into libc. C++ freestanding implementation, by the standard, is required to provide the runtime typeinfo, exceptions, intialization and termination support (i.e. atexit/cxa_atexit and most important cxa_thread_atexit, if you use TLS) and so on. It clearly gives the cycle in the dependencies. There is no requirement on the compilers to not use these features in unexpected ways, and looking at the current compiler evolution, I do expect that these features would bite us simply because we allowed C++ code in libc. We already have some issues die to the jemalloc reliance on pthreads, which makes the bootstraping a problem. We have to maintain the ugly fake init trick to postpone malloc for the mutexes backing store inside libthr to allow jemalloc to initialize without causing cyclic dependencies. Also, our C runtime (rtld/libc/libthr and perhaps libm) is currently only requires C compiler (and assembler and linker) to compile. Having C++ requirement for compilation, assuming the runtime issues I noted above are somewhat avoided, is also not a move I consider useful. Summary is that, in my opinion, requiring C++ compiler and working runtime for malloc(3) implementation is not desirable. If this goes in, low-level parts of the libc and whole libthr must grow private malloc implementation to not depend on libc malloc. Currently only rtld has private malloc (for similar reasons). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
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=powerpc64 and TARGET_ARCH=powerpc : 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=powerpc 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 in use in both cases. I do build the kernel and world for TARGET_ARCH=powerpc64 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=powerpc64 TOOLS_TO_TYPE=${TO_TYPE} VERSION_CONTEXT=12.0 # KERNCONF=GENERIC64vtsc-NODBG TARGET=powerpc .if ${.MAKE.LEVEL} == 0 TARGET_ARCH=${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER= WITHOUT_SYSTEM_COMPILER= # WITH_LIBCPLUSPLUS= WITHOUT_BINUTILS_BOOTSTRAP= WITH_ELFTOOLCHAIN_BOOTSTRAP= WITH_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EXTRAS= WITHOUT_LLD_BOOTSTRAP= WITH_LLD= WITHOUT_LLD_IS_LD= WITH_LLDB= # WITH_BOOT= WITH_LIB32= # WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= WITHOUT_GCC_IS_CC= WITHOUT_GNUCXX= # NO_WERROR= MALLOC_PRODUCTION= # # Avoid converts between pointers to integer types with different sign [-Werror,-Wpointer-sign] # and such from blocking the build. WERROR= # WITH_REPRODUCIBLE_BUILD= WITH_DEBUG_FILES= # # # 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=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} == 0 # # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX # binding automatically. # XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=/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=/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=powerpc # KERNCONF=GENERICvtsc-NODBG TARGET=${TO_TYPE} .if ${.MAKE.LEVEL} == 0 TARGET_ARCH=${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER= WITHOUT_SYSTEM_COMPILER= # WITH_LIBCPLUSPLUS= WITH_BINUTILS_BOOTSTRAP= WITH_ELFTOOLCHAIN_BOOTSTRAP= WITH_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= WITH_CLANG_EX
Re: C++ in jemalloc
I'm guessing a realistic timeline for us would be on the order of 3 to 6 months. We've been dithering on this issue for a while, and your request seems as good a time as any to get people off the fence... So, if you are targeting FreeBSD 12, then in that time frame, there'd be no issues with C++11 in the form you characterized. FreeBSD 11.x couldn't handle requiring a c++11 compiler to build though, and we're planning another release of that soon. Warner On Thu, Oct 5, 2017 at 4:50 PM, David Goldblatt wrote: > We can avoid it in the short term without a ton of pain. In the long run > it would be nice to have, but I wouldn't want to tie our release schedule > to FreeBSD's too tightly (our CI is improving to the point where the tip of > the dev branch gets tested about as well as releases would be, so we're > trying to de-emphasize release vs. non-release versions). Do you have a > sense of when the situation might change (if only so I know when to check > back)? > > Thanks for the replies on this, they've been super helpful. > > - David > > > On Thu, Oct 5, 2017 at 4:13 PM, Warner Losh wrote: > >> Today C++11 is a no-go generally due to the lagging architectures needing >> gcc 4.2. >> >> However, that answer might change soon. Would it be easy for you to avoid >> C++11, or would that cause you significant pain? And what's the timeline >> you'd be releasing a new jemalloc requiring this stuff? The answers might >> change the 'no-go' to 'ok'. >> >> Warner >> >> >> On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt < >> davidtgoldbl...@gmail.com> wrote: >> >>> So it sounds like C++03 (or rather, the version of C++ supported by g++ >>> 4.2) will be fine. >>> >>> > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It >>> isn't clear to me if having to use the ports gcc to build was unfortunate >>> or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the >>> core implementation (we currently have to maintain our own backport of C11 >>> atomics, for instance), but would be really helpful in the test suite >>> (because of how much syntactically simpler it is to, say, spin up a bunch >>> of threads to hammer a local instance of a data structure). >>> >>> - David >>> >>> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: >>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > > wrote: > > > > > > > > Hi all, > > > > > > The jemalloc developers have wanted to start using C++ for a > while, to > > > enable some targeted refactorings of code we have trouble > maintaining due > > > to brittleness or complexity (e.g. moving thousand line macro > definitions > > > to templates, changing the build->extract symbols->rebuild > mangling scheme > > > for internal symbols to one using C++ namespaces). We'd been > holding off > > > because we thought that FreeBSD base all had to compile on GCC > 4.2, in > > > order to support some esoteric architectures[1]. > > > > > > The other day though, I noticed that there is some C++ shipping > with > > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the > HACKING > > > document that C++11 is a minimum for FreeBSD 11). This, combined > with the > > > fact that ports now points to a modern gcc, makes me think we were > > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > > > Am I right? Will anything break if jemalloc needs a C++ compiler > to build? > > > We will of course not use exceptions, RTTI, global constructors, > the C++ > > > stdlib, or anything else that might affect C source or link > compatibility. > > > > > > Thanks, > > > David (on behalf of the jemalloc developers > > > > > > [1] That being said, we don't compile or test on those > architectures, and > > > so probably don't work there in the first place if I'm being > honest. But > > > we'd also like to avoid making that a permanent state of affairs > that can't > > > be changed. > > > > > For FreeBSD 10 and earlier, this would likely break all > architectures that > > aren't x86. 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). > > > > So for the popular architectures, this arrangement might work. For > building > > with external toolchains, it might also work. Some of the less > popular > > architectures may be a problem. > > > > Does that help? It isn't completely cut and dried, but it should be > helpful > > for you making a decision. > > > > Warner > > Wait a sec... we've been compiling
Re: C++ in jemalloc
In particular, it is expected that FreeBSD 12 will not ship with GCC 4.2 and that all supported architectures in FreeBSD 12 will be using a C++11-capable toolchain (either external GCC or in-tree clang). However, older releases will still be restricted to C++03 (or whatever GCC 4.2 supports) including future releases on FreeBSD 11. Also, FreeBSD-HEAD's tree is not yet in a position where all architectures are using a C++11-capable toolchain. On Thursday, October 05, 2017 04:13:08 PM Warner Losh wrote: > Today C++11 is a no-go generally due to the lagging architectures needing > gcc 4.2. > > However, that answer might change soon. Would it be easy for you to avoid > C++11, or would that cause you significant pain? And what's the timeline > you'd be releasing a new jemalloc requiring this stuff? The answers might > change the 'no-go' to 'ok'. > > Warner > > > On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt > wrote: > > > So it sounds like C++03 (or rather, the version of C++ supported by g++ > > 4.2) will be fine. > > > > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It > > isn't clear to me if having to use the ports gcc to build was unfortunate > > or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the > > core implementation (we currently have to maintain our own backport of C11 > > atomics, for instance), but would be really helpful in the test suite > > (because of how much syntactically simpler it is to, say, spin up a bunch > > of threads to hammer a local instance of a data structure). > > > > - David > > > > On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > > > >> > >> > >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > >> > >>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > >>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > >>> > wrote: > >>> > > >>> > > > >>> > > Hi all, > >>> > > > >>> > > The jemalloc developers have wanted to start using C++ for a while, > >>> to > >>> > > enable some targeted refactorings of code we have trouble > >>> maintaining due > >>> > > to brittleness or complexity (e.g. moving thousand line macro > >>> definitions > >>> > > to templates, changing the build->extract symbols->rebuild mangling > >>> scheme > >>> > > for internal symbols to one using C++ namespaces). We'd been holding > >>> off > >>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, > >>> in > >>> > > order to support some esoteric architectures[1]. > >>> > > > >>> > > The other day though, I noticed that there is some C++ shipping with > >>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the > >>> HACKING > >>> > > document that C++11 is a minimum for FreeBSD 11). This, combined > >>> with the > >>> > > fact that ports now points to a modern gcc, makes me think we were > >>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. > >>> > > > >>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to > >>> build? > >>> > > We will of course not use exceptions, RTTI, global constructors, the > >>> C++ > >>> > > stdlib, or anything else that might affect C source or link > >>> compatibility. > >>> > > > >>> > > Thanks, > >>> > > David (on behalf of the jemalloc developers > >>> > > > >>> > > [1] That being said, we don't compile or test on those > >>> architectures, and > >>> > > so probably don't work there in the first place if I'm being honest. > >>> But > >>> > > we'd also like to avoid making that a permanent state of affairs > >>> that can't > >>> > > be changed. > >>> > > > >>> > For FreeBSD 10 and earlier, this would likely break all architectures > >>> that > >>> > aren't x86. 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). > >>> > > >>> > So for the popular architectures, this arrangement might work. For > >>> building > >>> > with external toolchains, it might also work. Some of the less popular > >>> > architectures may be a problem. > >>> > > >>> > Does that help? It isn't completely cut and dried, but it should be > >>> helpful > >>> > for you making a decision. > >>> > > >>> > Warner > >>> > >>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like > >>> 2006. What am I missing here that keeps this answer from being a > >>> simple "go for it"? > >>> > >>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC > >>> may require C++11, but that was likely the author's choice given that > >>> there was no requirement for it to work on pre-clang versions of > >>> freebsd). > >>> > >> > >> It's the ubiquity of C++11 is why I didn't just say "Go for it". > >> > >> Warner > >> > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send
Re: C++ in jemalloc
We can avoid it in the short term without a ton of pain. In the long run it would be nice to have, but I wouldn't want to tie our release schedule to FreeBSD's too tightly (our CI is improving to the point where the tip of the dev branch gets tested about as well as releases would be, so we're trying to de-emphasize release vs. non-release versions). Do you have a sense of when the situation might change (if only so I know when to check back)? Thanks for the replies on this, they've been super helpful. - David On Thu, Oct 5, 2017 at 4:13 PM, Warner Losh wrote: > Today C++11 is a no-go generally due to the lagging architectures needing > gcc 4.2. > > However, that answer might change soon. Would it be easy for you to avoid > C++11, or would that cause you significant pain? And what's the timeline > you'd be releasing a new jemalloc requiring this stuff? The answers might > change the 'no-go' to 'ok'. > > Warner > > > On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt > wrote: > >> So it sounds like C++03 (or rather, the version of C++ supported by g++ >> 4.2) will be fine. >> >> Is C++11 a no-go, without breaking libc on non-Clang architectures? (It >> isn't clear to me if having to use the ports gcc to build was unfortunate >> or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the >> core implementation (we currently have to maintain our own backport of C11 >> atomics, for instance), but would be really helpful in the test suite >> (because of how much syntactically simpler it is to, say, spin up a bunch >> of threads to hammer a local instance of a data structure). >> >> - David >> >> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: >> >>> >>> >>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: >>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > wrote: > > > > > Hi all, > > > > The jemalloc developers have wanted to start using C++ for a while, to > > enable some targeted refactorings of code we have trouble maintaining due > > to brittleness or complexity (e.g. moving thousand line macro definitions > > to templates, changing the build->extract symbols->rebuild mangling scheme > > for internal symbols to one using C++ namespaces). We'd been holding off > > because we thought that FreeBSD base all had to compile on GCC 4.2, in > > order to support some esoteric architectures[1]. > > > > The other day though, I noticed that there is some C++ shipping with > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > > document that C++11 is a minimum for FreeBSD 11). This, combined with the > > fact that ports now points to a modern gcc, makes me think we were > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > > We will of course not use exceptions, RTTI, global constructors, the C++ > > stdlib, or anything else that might affect C source or link compatibility. > > > > Thanks, > > David (on behalf of the jemalloc developers > > > > [1] That being said, we don't compile or test on those architectures, and > > so probably don't work there in the first place if I'm being honest. But > > we'd also like to avoid making that a permanent state of affairs that can't > > be changed. > > > For FreeBSD 10 and earlier, this would likely break all architectures that > aren't x86. 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). > > So for the popular architectures, this arrangement might work. For building > with external toolchains, it might also work. Some of the less popular > architectures may be a problem. > > Does that help? It isn't completely cut and dried, but it should be helpful > for you making a decision. > > Warner Wait a sec... we've been compiling C++ code with gcc 4.2 since like 2006. What am I missing here that keeps this answer from being a simple "go for it"? Just stay away from C++11 features and gcc 4.2 should work fine. (DTC may require C++11, but that was likely the author's choice given that there was no requirement for it to work on pre-clang versions of freebsd). >>> >>> It's the ubiquity of C++11 is why I didn't just say "Go for it". >>> >>> Warner >>> >> >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebs
Re: C++ in jemalloc
Today C++11 is a no-go generally due to the lagging architectures needing gcc 4.2. However, that answer might change soon. Would it be easy for you to avoid C++11, or would that cause you significant pain? And what's the timeline you'd be releasing a new jemalloc requiring this stuff? The answers might change the 'no-go' to 'ok'. Warner On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt wrote: > So it sounds like C++03 (or rather, the version of C++ supported by g++ > 4.2) will be fine. > > Is C++11 a no-go, without breaking libc on non-Clang architectures? (It > isn't clear to me if having to use the ports gcc to build was unfortunate > or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the > core implementation (we currently have to maintain our own backport of C11 > atomics, for instance), but would be really helpful in the test suite > (because of how much syntactically simpler it is to, say, spin up a bunch > of threads to hammer a local instance of a data structure). > > - David > > On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > >> >> >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: >> >>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >>> > wrote: >>> > >>> > > >>> > > Hi all, >>> > > >>> > > The jemalloc developers have wanted to start using C++ for a while, >>> to >>> > > enable some targeted refactorings of code we have trouble >>> maintaining due >>> > > to brittleness or complexity (e.g. moving thousand line macro >>> definitions >>> > > to templates, changing the build->extract symbols->rebuild mangling >>> scheme >>> > > for internal symbols to one using C++ namespaces). We'd been holding >>> off >>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, >>> in >>> > > order to support some esoteric architectures[1]. >>> > > >>> > > The other day though, I noticed that there is some C++ shipping with >>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >>> HACKING >>> > > document that C++11 is a minimum for FreeBSD 11). This, combined >>> with the >>> > > fact that ports now points to a modern gcc, makes me think we were >>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >>> > > >>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >>> build? >>> > > We will of course not use exceptions, RTTI, global constructors, the >>> C++ >>> > > stdlib, or anything else that might affect C source or link >>> compatibility. >>> > > >>> > > Thanks, >>> > > David (on behalf of the jemalloc developers >>> > > >>> > > [1] That being said, we don't compile or test on those >>> architectures, and >>> > > so probably don't work there in the first place if I'm being honest. >>> But >>> > > we'd also like to avoid making that a permanent state of affairs >>> that can't >>> > > be changed. >>> > > >>> > For FreeBSD 10 and earlier, this would likely break all architectures >>> that >>> > aren't x86. 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). >>> > >>> > So for the popular architectures, this arrangement might work. For >>> building >>> > with external toolchains, it might also work. Some of the less popular >>> > architectures may be a problem. >>> > >>> > Does that help? It isn't completely cut and dried, but it should be >>> helpful >>> > for you making a decision. >>> > >>> > Warner >>> >>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >>> 2006. What am I missing here that keeps this answer from being a >>> simple "go for it"? >>> >>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >>> may require C++11, but that was likely the author's choice given that >>> there was no requirement for it to work on pre-clang versions of >>> freebsd). >>> >> >> It's the ubiquity of C++11 is why I didn't just say "Go for it". >> >> Warner >> > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
(apologies if you receive this twice; I subscribed to the list in order to flip the needs-moderation bit for my posts). So it sounds like C++03 (or rather, the version of C++ supported by g++ 4.2) will be fine. Is C++11 a no-go, without breaking libc on non-Clang architectures? (It isn't clear to me if having to use the ports gcc to build was unfortunate or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the core implementation (we currently have to maintain our own backport of C11 atomics, for instance), but would be really helpful in the test suite (because of how much syntactically simpler it is to, say, spin up a bunch of threads to hammer a local instance of a data structure). On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh wrote: > > > On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > >> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >> > wrote: >> > >> > > >> > > Hi all, >> > > >> > > The jemalloc developers have wanted to start using C++ for a while, to >> > > enable some targeted refactorings of code we have trouble maintaining >> due >> > > to brittleness or complexity (e.g. moving thousand line macro >> definitions >> > > to templates, changing the build->extract symbols->rebuild mangling >> scheme >> > > for internal symbols to one using C++ namespaces). We'd been holding >> off >> > > because we thought that FreeBSD base all had to compile on GCC 4.2, in >> > > order to support some esoteric architectures[1]. >> > > >> > > The other day though, I noticed that there is some C++ shipping with >> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >> HACKING >> > > document that C++11 is a minimum for FreeBSD 11). This, combined with >> the >> > > fact that ports now points to a modern gcc, makes me think we were >> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >> > > >> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >> build? >> > > We will of course not use exceptions, RTTI, global constructors, the >> C++ >> > > stdlib, or anything else that might affect C source or link >> compatibility. >> > > >> > > Thanks, >> > > David (on behalf of the jemalloc developers >> > > >> > > [1] That being said, we don't compile or test on those architectures, >> and >> > > so probably don't work there in the first place if I'm being honest. >> But >> > > we'd also like to avoid making that a permanent state of affairs that >> can't >> > > be changed. >> > > >> > For FreeBSD 10 and earlier, this would likely break all architectures >> that >> > aren't x86. 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). >> > >> > So for the popular architectures, this arrangement might work. For >> building >> > with external toolchains, it might also work. Some of the less popular >> > architectures may be a problem. >> > >> > Does that help? It isn't completely cut and dried, but it should be >> helpful >> > for you making a decision. >> > >> > Warner >> >> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >> 2006. What am I missing here that keeps this answer from being a >> simple "go for it"? >> >> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >> may require C++11, but that was likely the author's choice given that >> there was no requirement for it to work on pre-clang versions of >> freebsd). >> > > It's the ubiquity of C++11 is why I didn't just say "Go for it". > > Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote: > On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > > wrote: > > > > > > > > Hi all, > > > > > > The jemalloc developers have wanted to start using C++ for a while, to > > > enable some targeted refactorings of code we have trouble maintaining > due > > > to brittleness or complexity (e.g. moving thousand line macro > definitions > > > to templates, changing the build->extract symbols->rebuild mangling > scheme > > > for internal symbols to one using C++ namespaces). We'd been holding > off > > > because we thought that FreeBSD base all had to compile on GCC 4.2, in > > > order to support some esoteric architectures[1]. > > > > > > The other day though, I noticed that there is some C++ shipping with > > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the > HACKING > > > document that C++11 is a minimum for FreeBSD 11). This, combined with > the > > > fact that ports now points to a modern gcc, makes me think we were > > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > > > Am I right? Will anything break if jemalloc needs a C++ compiler to > build? > > > We will of course not use exceptions, RTTI, global constructors, the > C++ > > > stdlib, or anything else that might affect C source or link > compatibility. > > > > > > Thanks, > > > David (on behalf of the jemalloc developers > > > > > > [1] That being said, we don't compile or test on those architectures, > and > > > so probably don't work there in the first place if I'm being honest. > But > > > we'd also like to avoid making that a permanent state of affairs that > can't > > > be changed. > > > > > For FreeBSD 10 and earlier, this would likely break all architectures > that > > aren't x86. 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). > > > > So for the popular architectures, this arrangement might work. For > building > > with external toolchains, it might also work. Some of the less popular > > architectures may be a problem. > > > > Does that help? It isn't completely cut and dried, but it should be > helpful > > for you making a decision. > > > > Warner > > Wait a sec... we've been compiling C++ code with gcc 4.2 since like > 2006. What am I missing here that keeps this answer from being a > simple "go for it"? > > Just stay away from C++11 features and gcc 4.2 should work fine. (DTC > may require C++11, but that was likely the author's choice given that > there was no requirement for it to work on pre-clang versions of > freebsd). > It's the ubiquity of C++11 is why I didn't just say "Go for it". Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > wrote: > > > > > Hi all, > > > > The jemalloc developers have wanted to start using C++ for a while, to > > enable some targeted refactorings of code we have trouble maintaining due > > to brittleness or complexity (e.g. moving thousand line macro definitions > > to templates, changing the build->extract symbols->rebuild mangling scheme > > for internal symbols to one using C++ namespaces). We'd been holding off > > because we thought that FreeBSD base all had to compile on GCC 4.2, in > > order to support some esoteric architectures[1]. > > > > The other day though, I noticed that there is some C++ shipping with > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > > document that C++11 is a minimum for FreeBSD 11). This, combined with the > > fact that ports now points to a modern gcc, makes me think we were > > incorrect, and can turn on C++ without breaking FreeBSD builds. > > > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > > We will of course not use exceptions, RTTI, global constructors, the C++ > > stdlib, or anything else that might affect C source or link compatibility. > > > > Thanks, > > David (on behalf of the jemalloc developers > > > > [1] That being said, we don't compile or test on those architectures, and > > so probably don't work there in the first place if I'm being honest. But > > we'd also like to avoid making that a permanent state of affairs that can't > > be changed. > > > For FreeBSD 10 and earlier, this would likely break all architectures that > aren't x86. 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). > > So for the popular architectures, this arrangement might work. For building > with external toolchains, it might also work. Some of the less popular > architectures may be a problem. > > Does that help? It isn't completely cut and dried, but it should be helpful > for you making a decision. > > Warner Wait a sec... we've been compiling C++ code with gcc 4.2 since like 2006. What am I missing here that keeps this answer from being a simple "go for it"? Just stay away from C++11 features and gcc 4.2 should work fine. (DTC may require C++11, but that was likely the author's choice given that there was no requirement for it to work on pre-clang versions of freebsd). -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 5, 2017 at 3:01 PM, Warner Losh wrote: > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt > wrote: > >> Hi all, >> >> The jemalloc developers have wanted to start using C++ for a while, to >> enable some targeted refactorings of code we have trouble maintaining due >> to brittleness or complexity (e.g. moving thousand line macro definitions >> to templates, changing the build->extract symbols->rebuild mangling scheme >> for internal symbols to one using C++ namespaces). We'd been holding off >> because we thought that FreeBSD base all had to compile on GCC 4.2, in >> order to support some esoteric architectures[1]. >> >> The other day though, I noticed that there is some C++ shipping with >> FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING >> document that C++11 is a minimum for FreeBSD 11). This, combined with the >> fact that ports now points to a modern gcc, makes me think we were >> incorrect, and can turn on C++ without breaking FreeBSD builds. >> >> Am I right? Will anything break if jemalloc needs a C++ compiler to build? >> We will of course not use exceptions, RTTI, global constructors, the C++ >> stdlib, or anything else that might affect C source or link compatibility. >> >> Thanks, >> David (on behalf of the jemalloc developers >> >> [1] That being said, we don't compile or test on those architectures, and >> so probably don't work there in the first place if I'm being honest. But >> we'd also like to avoid making that a permanent state of affairs that can't >> be changed. >> > > For FreeBSD 10 and earlier, this would likely break all architectures that > aren't x86. 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). > > So for the popular architectures, this arrangement might work. For building > with external toolchains, it might also work. Some of the less popular > architectures may be a problem. > > Does that help? It isn't completely cut and dried, but it should be helpful > for you making a decision. > > Warner To be clear, Warner is talking about C++11 code in jemalloc. C++98 will work fine on all architectures, and I think most of C++03 will too. dtc(1) is allowed to use C++11 because it only builds on architectures that support it. -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: C++ in jemalloc
On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro definitions > to templates, changing the build->extract symbols->rebuild mangling scheme > for internal symbols to one using C++ namespaces). We'd been holding off > because we thought that FreeBSD base all had to compile on GCC 4.2, in > order to support some esoteric architectures[1]. > > The other day though, I noticed that there is some C++ shipping with > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the HACKING > document that C++11 is a minimum for FreeBSD 11). This, combined with the > fact that ports now points to a modern gcc, makes me think we were > incorrect, and can turn on C++ without breaking FreeBSD builds. > > Am I right? Will anything break if jemalloc needs a C++ compiler to build? > We will of course not use exceptions, RTTI, global constructors, the C++ > stdlib, or anything else that might affect C source or link compatibility. > > Thanks, > David (on behalf of the jemalloc developers > > [1] That being said, we don't compile or test on those architectures, and > so probably don't work there in the first place if I'm being honest. But > we'd also like to avoid making that a permanent state of affairs that can't > be changed. > For FreeBSD 10 and earlier, this would likely break all architectures that aren't x86. 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). So for the popular architectures, this arrangement might work. For building with external toolchains, it might also work. Some of the less popular architectures may be a problem. Does that help? It isn't completely cut and dried, but it should be helpful for you making a decision. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"