[cfe-dev] libc++abi on linux

[Ben Pope]

On Thursday, July 12, 2012 04:21 PM, David Chisnall wrote:
> 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.

OK, so let's assume I'd like to keep the C++ ABI compatible with the 
last few years of GCC (I want to use Clang, not base my entire platform 
on it, for now).  I also want to be able to use libc++. lets ignore STL 
compatibility for now - I know I'll have to also compile anything that 
uses STL in its interface if I want my new code to depend on it.  But, 
for example, I would like to be able to use openssl.so that my platform 
provides (presumably built by GCC 4.6).  I can't think of anything 
really common with a C++ interface.

>>> 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
> /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].

Oh.  compiler-rt, more to think about.  Awesomeness!

Can somebody explain to me the pieces of this puzzle?  There are a bunch 
of pieces on llvm.org, do they even belong to the same puzzle?
libc++
libc++abi
compiler-rt
The missing piece is libunwind?

What are the GNU toolchain equivalents?  Are there even 1:1 equivalents?

> David
> With his FreeBSD toolchain hat on

Thanks for your help, I'm slowly understanding the bigger picture.  Any 
good documentation out there I can go and read, rather than pester 
people here?

> <snip ARM stuff>

Lots of fun!

Ben