[LLVMdev] Unwinds gone missing

[Duncan Sands]

Hi Talin,

> 1) I'm trying to figure out the relationship between the __cxa_throw
> function, and the _Unwind_RaiseException function mentioned in the ABI doc.
> My guess is that _Unwind_RaiseException is the language-neutral
> implementation of stack unwinding, and __cxa_throw is the C++ exception
> semantics that are implemented on top of it. If that is the case, should I
> be calling _Unwind_RaiseException since my exceptions are more like Java
> than C++ exceptions?

try reading this: http://www.codesourcery.com/public/cxx-abi/abi-eh.html

> 2) How portable is _Unwind_RaiseException and similar functions? In
> particular, if I call those functions, will I be limiting myself to a subset
> of the platforms that LLVM supports? (The same question can be asked of
> __cxa_throw).
>
> Although _Unwind_RaiseException is mentioned as part of the Itanium ABI, it
> is apparently used on many more platform types than just that one processor.
> A code search shows that it is in fact part of the standard gcc-provided
> runtime libs (see
> http://www.google.com/codesearch/p?hl=en#47R7EH5FbNk/trunk/gcc/gcc/unwind-generic.h&q=_Unwind_RaiseException%20lang:c).

Exactly, this is part of libgcc and as such you can assume it is available.

> There is also a mention of "libunwind". Is libunwind a portable
> implementation of the Itanium unwinding ABI?

I think it's an attempt to have a non-gcc related platform independent
unwinding library.

> 3) I really like the "invoke/unwind" abstraction that LLVM provides, as it
> divorces the mechanism of unwinding from the creation of an exception
> object. However, looking at the Itanium unwinding API, I don't see how you
> can implement LLVM invoke/unwind on top of it, since the API functions take
> an exception object as a parameter. (I suppose you could use a dummy
> exception to satisfy the ABI, and then implement your own, separate
> exception object, but this destroys some of the efficiency of the unwinding
> implementation.)

Right, this is indeed one of the main problems in implementing unwind.
On the other hand invoke can be done fairly easily (in spite of appearances,
invoke is not supported by the code generators, only invoke + an eh.selector
call [provides a personality function] is supported; I have a plan to fix
this).

> Also, the Itanium ABI appears to offer some interesting features that aren't
> exposed by the invoke/unwind mechanism which would be useful. For example,
> the fact that the stack frames are traversed in two passes seems like it
> might make it possible to implement human-readable stack dumps, which would
> be difficult with invoke/unwind.

Check out http://llvm.org/docs/LangRef.html#int_frameaddress

Ciao,

Duncan.