[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