Re: C++ in jemalloc

On 2017-Oct-7, at 3:21 AM, Roman Divacky <rdivacky_at_vlakno.cz> 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 (0x50200000)

# ./a.out
Segmentation fault (core dumped)

#0  0x00000000501dfc20 in _Unwind_SetGR (context=<value optimized out>, index=<value optimized out>, val=1342451808) at unwind-dw2-fde.h:162
162	{
(gdb) bt
#0  0x00000000501dfc20 in _Unwind_SetGR (context=<value optimized out>, index=<value optimized out>, val=1342451808) at unwind-dw2-fde.h:162
#1  0x0000000050191194 in __gxx_personality_v0 (version=<value optimized out>, actions=<value optimized out>, exceptionClass=<value optimized out>, exceptionObject=0x50043060, 
    context=0xffffffffffffcc80) at /usr/src/contrib/libcxxrt/exception.cc:1203
#2  0x00000000501e0a60 in _Unwind_RaiseException_Phase2 (exc=0x50043060, context=0xffffffffffffcc80) at unwind.inc:66
#3  0x00000000501e0548 in _Unwind_RaiseException (exc=<value optimized out>) at unwind.inc:135
#4  0x00000000501904f4 in __cxa_throw (thrown_exception=<value optimized out>, tinfo=<value optimized out>, dest=<value optimized out>) at /usr/src/contrib/libcxxrt/exception.cc:774
#5  0x0000000010000898 in ?? ()

compared to system-clang's:

#0  0x0000000050530c20 in _Unwind_SetGR (context=<value optimized out>, index=<value optimized out>, val=1342447712) at unwind-dw2-fde.h:162
162	{
(gdb) bt
#0  0x0000000050530c20 in _Unwind_SetGR (context=<value optimized out>, index=<value optimized out>, val=1342447712) at unwind-dw2-fde.h:162
#1  0x0000000050190194 in __gxx_personality_v0 (version=<value optimized out>, actions=<value optimized out>, exceptionClass=<value optimized out>, exceptionObject=0x50042060, 
    context=0xffffffffffffcc60) at /usr/src/contrib/libcxxrt/exception.cc:1203
#2  0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060, context=0xffffffffffffcc60) at unwind.inc:66
#3  0x0000000050531548 in _Unwind_RaiseException (exc=<value optimized out>) at unwind.inc:135
#4  0x000000005018f4f4 in __cxa_throw (thrown_exception=<value optimized out>, tinfo=<value optimized out>, dest=<value optimized out>) at /usr/src/contrib/libcxxrt/exception.cc:774
#5  0x0000000010000d74 in main () at exception_test.cpp:5
#6  0x0000000010000ae8 in _start (argc=1342447624, argv=0x50042060, env=0xffffffffffffcc60, obj=<value optimized out>, cleanup=<value optimized out>, ps_strings=<value optimized out>)
    at /usr/src/lib/csu/powerpc64/crt1.c:94
#7  0x0000000050017b70 in .text () at /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104
Current language:  auto; currently minimal


The code generation involved is tied to (driven
by) the use of builtins, not just normal C/C++
code. Inlining is also mixed in.

There could be more wrong than I've noticed. At
some point comparing the dwarfdump output for gcc
and clang for the same "interesting" source(s)
being compiled would be appropriate, looking for
mismatches that are not equivalent.

(Unfortunately equivalence need not be a trivial
judgment to make since CFI is a programming language
of its own and the code being described is not
identical, possibly inlined differently even.)

So I'm building based on devel/powerpc64-xtoolchain-gcc
using WITH_LIBCPLUSPLUS= to compare against.

(I've not done a powerpc64-xtoolchain-gcc based build
in a long time. Hopefully it still builds to completion.)

It is far enough along now to have built a libcxxrt.so.1
so. . .

But I need sleep. (It is well after 8am here.) All I'm
managing to do is confuse myself at this point. I may
have been wrong about where the scratch register
initialization is inside the library, I'm not sure.




===
Mark Millard
markmi at dsl-only.net