[cfe-dev] unraveling libcxxabi/libcxx

Mon Apr 8 18:39:38 PDT 2013

I'm not sure what's wrong.  But my first guess is that the type_info for int isn't getting laid down by the compiler, or perhaps more than one is.

It surprised the heck out of me when I first discovered where and how this happens.  In:

libxxabi/src/private_typeinfo.cpp, line 79:

// __fundamental_type_info

// This miraculously (compiler magic) emits the type_info's for:
//   1. all of the fundamental types
//   2. pointers to all of the fundamental types
//   3. pointers to all of the const fundamental types
__fundamental_type_info::~__fundamental_type_info()
{
}

So possibilities include:

*  Maybe clang isn't actually laying down the type_info's for the fundamental types here.
*  Maybe the type_info's are getting laid down, but they aren't getting exported.
*  Maybe the type_info's are getting laid down, but not just here, but elsewhere too, and you're getting multiple type_info's for int.  For catch(int) to work, there must be only one type_info for int in the entire application.

Hope this helps.  I'm basically rambling without knowing what's going on, in the hopes that my random walk will accidentally hit a solution.

Howard

On Apr 8, 2013, at 9:31 PM, David Fang <fang at csl.cornell.edu> wrote:

> Hi Howard,
> 
> I whipped up another Makefile to compile tests to different executables, where the resulting commands look like:
> 
> /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++ -std=c++0x -stdlib=libc++ -O0 -no-integrated-as -I../include -cxx-isystem /usr/local/experimental/llvm/lib/libcxx/include/c++/v1 -I/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include unwind_01.cpp ../lib/libc++abi.1.dylib -L/usr/local/experimental/llvm/lib/libcxx/lib  -o unwind_01
> 
> Unfortunately, I get a ton of test failures.  Just to pick one arbitrarily:
> 
> % env DYLD_LIBRARY_PATH=../lib gdb ./unwind_01
> GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "powerpc-apple-darwin"...
> warning: --arch option not supported in this gdb.
> Reading symbols for shared libraries ..... done
> 
> (gdb) run
> Starting program: /Volumes/Isolde/sources/LLVM-svn/libcxxabi.git/test/unwind_01
> tcsh: Word too long.
> Reading symbols for shared libraries .++ done
> libc++abi.dylib: terminating with uncaught exception of type int
> 
> Program received signal SIGABRT, Aborted.
> 0x90047dac in kill ()
> (gdb) where
> #0  0x90047dac in kill ()
> #1  0x9012d7b4 in abort ()
> #2  0x00205a18 in abort_message ()
> #3  0x00205ce0 in _ZL25default_terminate_handlerv ()
> #4  0x00214738 in std::__terminate ()
> #5  0x00215888 in __cxxabiv1::call_terminate ()
> #6  0x0021580c in __cxxabiv1::scan_eh_tab ()
> #7  0x00214d38 in __gxx_personality_v0 ()
> #8  0x9143cbc0 in _Unwind_RaiseException ()
> #9  0x00212cd4 in __cxa_throw ()
> #10 0x000020c8 in f2 ()
> #11 0x0000212c in f1 ()
> #12 0x000021cc in main ()
> 
> I see how unwind_01.cpp is supposed to work.  Any idea why
> "throw 55;" isn't getting caught by catch(int)?
> 
> The libunwind I'm using happens to be the one shipped with libgcc_s.10.4.
> Not sure what Apple version number that would correspond to.
> 
> How can I go about debugging this?
> 
> Fang
> 
> 
>> On OS X, you can:
>> 
>> export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib
>> clang++ -std=c++11 -stdlib=libc++ -nostdinc++ -I<path-to-libcxx>/include -L<path-to-libcxx>/lib test.cpp
>> 
>> (sub in libc++abi where appropriate).  The DYLD_LIBRARY_PATH symbol can contain multiple paths, using ':' as a separator.
>> 
>> Howard
>> 
>> On Apr 3, 2013, at 6:30 PM, David Fang <fang at csl.cornell.edu> wrote:
>> 
>>> Hi Howard and all,
>>> 
>>> I was able to build libcxxabi and libcxx on powerpc-darwin8.
>>> I've documented my experiences here. http://www.csl.cornell.edu/~fang/sw/llvm/#libcxx
>>> 
>>> I might need some explanation for how the test suite is expected to be run.  The 'testit' script in libcxxabi doesn't even refer to the libc++abi.dylib that was built, so there must be some implicit assumptions in this script?
>>> 
>>> I'm hoping there's a way to test the dylib before having to install it.
>>> Likewise with libc++.
>>> 
>>> Fang
>>> 
>>>> On Apr 2, 2013, at 8:35 PM, David Fang <fang at csl.cornell.edu> wrote:
>>>> 
>>>>> Hi,
>>>>> 	I'm currently looking into porting libcxx to an ancient system (powerpc-darwin8), and I noticed that libcxx depends on libcxxabi. However, libcxxabi's sources include headers like <exception> which are expected to be in some C++ library.  Does it (mutually) depend on libcxx? Maybe this was obvious, but I take it libcxxabi needs a c++11 compiler to build, correct?  (This would be fine, as I have stage-1 clang built from gcc-4.0/libstdc++.)  Does one {libcxx,libcxxabi} need to be installed before the other, or should they be built cross-referencing each others include dirs?  In terms of shared-library dependencies, libcxx should link to libcxxabi, right?
>>>>> 
>>>>> Is there better documentation somewhere that I don't know about?
>>>>> All I see are html pages at http://libcxxabi.llvm.org and http://libcxx.llvm.org/.
>>>> 
>>>> Contributions to better documentation (and your experiences in doing this) are welcome. :-)
>>>> 
>>>> Yes, libcxxabi is the lower-level library.  libcxx should link to libcxxabi.
>>>> 
>>>> Yes, currently libcxxabi is using -std=c++0x and probably needs it, though I can't think offhand of a specific need.  If you need to, try changing that to -std=c++03.  If there's any breakage it will almost certainly be compile-time breakage.  So that is a safe experiment.
>>>> 
>>>> libcxxabi is designed to be ABI compatible with a gcc-4.2 era libstdc++.  And therefore could almost certainly use a libstdc++-4.2 set of headers if need be to build against (another untested theory).
>>>> 
>>>> As libcxxabi is the lower-level library, I would go with installing that first.  But understand you're traversing territory where few have gone before.
>>>> 
>>>> Keep us posted, and blogs of your experience which might help future porters are welcome.
>>>> 
>>>> Howard
>>>> 
>>> 
>>> --
>>> David Fang
>>> http://www.csl.cornell.edu/~fang/
>>> 
>> 
> 
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
> 