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: RFC how to use kernel procs/threads efficiently

[Rick Macklem]

Ian Lepore wrote:
>On Fri, 2017-10-06 at 19:02 +, Rick Macklem wrote:
>> Hi,
>>
>> I have now dropped the client side of Flexible File Layout for pNFS into head
>> and I believe it is basically working.
>> Currently when talking to mirrored DS servers, it does the Write and Commit
>> RPCs to the mirrors serially. This works, but is inefficient w.r.t. elapsed 
>> to to
>> completion.
>>
>> To do them concurrently, I need separate kernel processes/threads to do them.
>> I can think of two ways to do this:
>> 1 - The code that I have running in projects/pnfs-planb-server for the pNFS 
>> server
>>   side does a kproc_create() to create a kernel process that does the 
>> RPC and
>>   then krpc_exit()s.
>>   - This was easy to code and works. However, I am concerned that there 
>> is
>> going to be excessive overheads from doing all the kproc_create()s 
>> and
>> kproc_exit()s?
>>Anyone know if these calls will result in large overheads?
>> 2 - I haven't coded this, but the other way I can think of to do this is to
>>   create a pool of threads (kthread_create() is sufficient in this case, 
>> I
>>   think?) and then hand each RPC to an available thread so it can do the 
>> RPC.
>>   - Other than a little more complex coding, the main issue I see with 
>> this one
>> is "How many threads and when to create more/less of them.".
>>
>> Anyhow, any comments w.r.t. the merits of either of the above approaches
>> (or a suggestion of other ways to do this) would be appreciated, rick
>
>taskqueue(9) is an existing mechanism to enqueue functions to execute
>asynch using a pool of threads, but it doesn't answer the scalability
>questions.  In fact it may make them harder, inasmuch as I don't think
>there's a mechanism to dynamically adjust the number of threads after
>first calling taskqueue_start_threads().
Hmm, yes. Thanks for the pointer. I hadn't read "man taskqueue" until now.
The kernel RPC doesn't use this and I suspect that it is because of what you
said w.r.t. dynamically adjusting the # of threads.
However, it does save "hand coding" the queues for #2 and I'm lazy (plus
don't believe reinventing the wheel is the best plan).

I think I will try using taskqueue and just have a sysctl for #of-threads.
(Actually most of the code ends up the same, because basically they all
 end up with a function with a single argument that does the RPC. The
 only difference is what call starts the RPC.)

Anyone else have comments? rick
___
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-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"