[cfe-dev] Choosing the unwinder / C++ low-level libraries in Clang

Renato Golin renato.golin at linaro.org
Thu Jul 23 09:28:07 PDT 2015


On 23 July 2015 at 17:04, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> (...)
> On some GNUish platforms, the unwinder is in libgcc_s.so or libgcc_eh.a (for static linking).  Mixing generic unwind implementations is not supported by the Itanium ABI, so you need to pick one, typically the one that the platform defines.  This also needs to be used for C code for __attribute__((cleanup)) to work (and for setjmp/longjmp to work on some platforms, though possibly only Itanium).

Great Scott! I got lost in the first paragraph... :(


> I’m not sure what your distinction of Unwind vs EH ABI means.  The Itanium ABI spec has two parts:
>
> - The generic unwinder
> - The language-specific EH personality functions (and throw / catch functions).

I'm not an expert on this, but I thought libunwind had the generic
unwinder and libc++abi had bundled the EH specific, including the
personality routines, as well as the rest of the C++ ABI.


> I thought the unwinder only used C++ features that didn’t depend on the C++ runtime library (no exceptions, no RTTI) and only depended on some header-only things from elsewhere?

I'm lost... :(

So, the real bug here is what I introduced years ago: compiler-rt
should *not* automatically include libgcc_s nor _eh. This one I need
to revert, but I wanted to put something to replace it.

>From the looks of it, it's going to be a lot more complicated than I
can possibly foresee. So, I think I should revert my change now
without a replacement. At least I can test libunwind and libc++abi
this way.

Fair enough?

--renato




More information about the cfe-dev mailing list