[cfe-dev] libc++abi on linux

David Chisnall csdavec at swan.ac.uk
Thu Jul 12 01:21:17 PDT 2012

On 12 Jul 2012, at 04:53, Ben Pope wrote:

> Right, but when I build the STL library, I need to specify which ABI 
> library it's going to use, and when I build the ABI library I need to 
> specify which unwind it's going to use, right?

Yes, but these are very important decisions for whoever is defining the C++ ABI for your platform (possibly you) to make.  Hiding them in the compiler wouldn't make life any easier.  In the GNU world it's traditionally easy: you just use all of the GNU stack or none of it.  LLVM is more modular.

>>> What does the rest of LLVM/clang community use?
>> In FreeBSD 9.1 (entering beta right about now), we are shipping libstdc++ and libc++, with libstdc++ linked against either libsupc++ or libcxxrt and libc++ linked against libc++. This is a preview release of libc++, so to mix it with libstdc++ in the same executable you need to add a libmap.conf entry telling libstdc++ to pick up libcxxrt instead of libsupc++. In 10.0, we will provide a libstdc++ linked to libcxxrt for legacy compatibility.
>> All that users need to do is specify -stdlib=libc++.  This will be the default on 10.0, and probably be the default when -std=c++11 before then.
> Can you tell me what the output of ldd libc++.so.1 is?

ldd /usr/lib/libc++.so
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8016af000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8018c8000)
	libc.so.7 => /lib/libc.so.7 (0x80081c000)

Some time before 10.0, libgcc_s.so there will go away and be replaced by compiler-rt + libunwind.  This is slowly edging up my to-do list.  Doing that for x86 is trivial.  For ARM, the libunwind parts are not well tested and libcxxrt (and libsupc++ both GCC and GNUstep libobjc) use some GNU EABI functions that aren't yet in compiler-rt for unwinding the stack[1].  

I've only tested the libcxxrt parts on ARM/Linux, which should be the same EH ABI as FreeBSD (although given the pathological aversion to documentation that appears to be suffered by the g++ ABI team, who knows), and it works well there with libgcc_s.   LLVM emits complete nonsense instead of unwind tables on ARM.  The ARM compiler folks know about this, but it's not yet near the top of their TODO list.  

With his FreeBSD toolchain hat on

[1] Unlike the Itanium ABI, the ARM EH ABI makes it the personality function's job to unwind the stack.  libgcc_s provides some helper functions so that you don't need to duplicate a load of code in every unwinder.  ARMv8, finally, fixes this abomination, so it should go away in 5-10 years...

More information about the cfe-dev mailing list