[LLVMdev] unwind/invoke design

Talin viridia at gmail.com
Mon Jun 15 22:57:13 PDT 2009

Wesley W. Terpstra wrote:
>> That said,
>> it wouldn't be too hard to support "unwind" in the code generators.
>> It would basically mean creating thread-local storage to hold dwarf
>> exception information, and turning "unwind" into some code to set up
>> the info and call the appropriate libgcc routine.
> Why does 'unwind' need to setup thread local storage at all? In my
> opinion this is the responsibility of the frontend, not LLVM. All I
> expect 'unwind' to do is unwind the stack down to the nearest 'unwind
> label' of an invoke. Thread-local storage, global variable, or any
> other approach one might think of to carry the exception information
> is a frontend policy decision. Adding this support to 'unwind'
> complicates its implementation and also dilutes its usefulness.
Much to my surprise, I discovered that you do not need thread-local data 
at all - the address of the exception object can be passed in to the 
landing pad code by directly modifying a register (via the libunwind 
library API). The libunwind API also allows specification of a cleanup 
function to deallocate the exception object, although this is not needed 
in my case because I use garbage collection.

Since my previous posted example apparently turned out to be useful 
after all, maybe I should look in to putting it somewhere more permanent...

-- Talin

More information about the llvm-dev mailing list