Re: C++ in jemalloc

[David Goldblatt]

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 <davidtgoldbl...@gmail.com>
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

[Mark Millard]

[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 828   

Re: C++ in jemalloc

[Mark Millard]

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 

Re: C++ in jemalloc

[Mark Millard]

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 

Re: C++ in jemalloc

[Roman Divacky]

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 
> >> 

Re: C++ in jemalloc

[Roman Divacky]

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 

Re: C++ in jemalloc

[Mark Millard]

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  

Re: C++ in jemalloc

[Mark Millard]

[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 

Re: C++ in jemalloc

[Mark Millard]

[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 

Re: C++ in jemalloc

[Mark Millard]

[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 

Re: C++ in jemalloc

[Mark Millard]

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

[Mark Millard]

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

[Conrad Meyer]

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

[Ian Lepore]

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

[Mark Millard]

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 

Re: C++ in jemalloc

[Warner Losh]

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

[Conrad Meyer]

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

[Justin Hibbits]

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

[Konstantin Belousov]

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

[Mark Millard]

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=

Re: C++ in jemalloc

[Warner Losh]

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 <davidtgoldbl...@gmail.com>
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 <i...@bsdimp.com> 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 <i...@bsdimp.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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.
>>>>> > >
>>>>> 

Re: C++ in jemalloc

[John Baldwin]

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 <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 <i...@bsdimp.com> wrote:
> >
> >>
> >>
> >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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 fin

Re: C++ in jemalloc

[David Goldblatt]

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 <i...@bsdimp.com> 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 <i...@bsdimp.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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 fi

Re: C++ in jemalloc

[Warner Losh]

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 <i...@bsdimp.com> wrote:
>
>>
>>
>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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

[David Goldblatt]

(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 <i...@bsdimp.com> wrote:

>
>
> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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

[Warner Losh]

On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <i...@freebsd.org> 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

[Ian Lepore]

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

[Alan Somers]

On Thu, Oct 5, 2017 at 3:01 PM, Warner Losh <i...@bsdimp.com> wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt <davidtgoldbl...@gmail.com>
> 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

[Warner Losh]

On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt <davidtgoldbl...@gmail.com>
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"

C++ in jemalloc

[David Goldblatt]

 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"