[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