[LLVMdev] Unwinds gone missing

[Talin]

On Mon, Dec 29, 2008 at 6:55 AM, Duncan Sands <baldrick at free.fr> wrote:

> 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


I did :)

I was also looking at this article, which purports to use
__Unwind_RaiseException directly:
http://www.incasoftware.de/~kamm/projects/index.php/2008/08/19/exception-handling-in-llvmdc-using-llvm/


>
> > 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


I knew about that function - the issue isn't so much getting the stack
frames, as it is knowing whether or not you'll need them. For most
exceptions, we would want to simply have the exception be caught and resume
execution, in which case saving the state of the stack is a waste of time.
However, in some cases you are going to print out the stack trace, which
means you need to record the stack frames before you enter the catch handler
(because then it's too late).

The Itanium exception document describes a process where the stack frames
between the throw and catch statements can be traversed multiple times.
Assuming the compiler knows whether a given catch handler makes reference to
the stack trace property of the exception, we can use this information to
decide whether or not to allocate space for the stack trace. That is, do a
pre-traversal to determine which catch handler will be called and whether
stack trace information is needed. If so, then do another traversal to
capture the stack trace, and then a final traversal to do the actual
unwinding.

Doing something similar using only the LLVM invoke/unwind primitives would
be very difficult I think.

>
> Ciao,
>
> Duncan.
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081229/2fa24653/attachment.html>