[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

Mark Shannon 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:
> http://llvm.org/docs/Passes.html#lowerinvoke

*Begin rant*

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* ;)


> Nick
>> Ciao,
>> Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list