[LLVMdev] One way to support unwind on x86

Nicolas Geoffray nicolas.geoffray at lip6.fr
Tue Mar 3 02:38:19 PST 2009


Hi Duncan, Hi Bjarke,

Duncan Sands wrote:
> Take a look at libunwind (http://www.hpl.hp.com/research/linux/libunwind/).
> Another possibility, very close you yours and currently used by the vmkit
> project, is to modify all functions so they return two values, the usual
> return value and an additional boolean value indicating whether an exception
> was thrown during the call or not.  Callers then branch to an appropriate
> place based on this value.  Thus there is no special stack unwinding, it
> is just functions returning.  This adds some distributed overhead, but
> unwinding is fast.  You can always return something more complicated than
> a boolean of course.
>   


That's correct. Although, to make things clear, I'm not using the 
multiple return value features of LLVM. The signature of functions only 
return one value. If an exception happens, the boolean value is stored 
in a thread local specific variable. But conceptually, this pretty much 
is the same than returning two values.

> The vmkit experience is that unwinding using their method is a lot faster
> than using the dwarf unwinder.  I don't know if the distributed overhead
> is noticeable or not.
>   

It's *hardly* noticeable. If your language/runtime throws a lot of 
exceptions, that's the way to go currently (there are other 
sophisticated techniques, but much more complex). Dwarf is great if your 
language/runtime basically never throws exceptions. I can't give you an 
accurate measure of the real cost of Dwarf on Java applications because, 
unfortunately, libgcc did not optimize its dwarf info lookup on 
dynamically registered frames. It's doing a linear search of the info, 
and that takes *a lot* of time.

Nicolas



More information about the llvm-dev mailing list