[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]
marks at dcs.gla.ac.uk
Mon Jul 20 04:31:11 PDT 2009
Nick Johnson wrote:
>> probably there should be a switch to choose whether codegen should turn
>> unwind/invoke into dwarf or setjmp/longjmp style code.
It seems to me that there is an implicit, and undocumented, assumption
that unwinding needs to handle stack-allocated objects.
In languages without stack-allocated objects (ie. most languages that
support exceptions) there is no need to unwind frame-by-frame, the
unwind simply needs to make a single jump to the invoke instruction and
restore the context (which in x86 is just 6 registers).
> There is, but it happens before codegen and is slow.
> -enable-correct-eh-support will translate invoke/unwind into
> setjmp/longjmp pairs for the correct behavior. See:
It is possible to implement invoke/unwind in such a way that both invoke
*and* unwind are fast, when unwind just unwinds and doesn't perform
any magic behind-the-scenes operations.
After all, isn't it the job of the front-end to insert all the clean-up
code for stack-allocated objects?
Java, C#, Python, and Ruby have destructors(finalizers), but they are
managed by the garbage collector.
C++ is the odd one out, so why do the semantics of an llvm instruction
depend on C++ semantics?
*End rant* ;)
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev