[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Mark Shannon]

Andrew Haley wrote:
> Mark Shannon wrote:
>> Andrew Haley wrote:
>>> Mark Shannon wrote:
>>>> Andrew Haley wrote:
>>>>> Mark Shannon wrote:
>>>>>> 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).
>>>>> Not quite.  It's also necessary to execute all the pending POSIX
>>>>> pthread_cleanup_pop() actions.
>>>> POSIX pthread_cleanup_pop() can only be called directly from C++/C.
>>>> C doesn't haven't exceptions.
>>> But it does have pthread_exit().
>>>
>>>> So yet again, this is a C++ issue.
>>> No, it isn't:
>>>
>>>        The effect of calling longjmp() or siglongjmp() is undefined  if  there
>>>        have  been any calls to pthread_cleanup_push() or pthread_cleanup_pop()
>>>        made without the matching call since the jump buffer  was  filled.
>>>
>> We are not talking about longjmp() or siglongjmp() we are talking about 
>> invoke/unwind!
> 
> Let's go back a bit.  Your claim is that there is no need to unwind
> frame-by-frame, an unwind simply needs to make a single jump to an
> invoke instruction and restore the context (which in x86 is just 6
> registers).  (This is, more or less, what longjmp() does.)  Duncan Sands
> explained to you why that wouldn't work, saying "if you throw an
> exception using your proposed unwind implementation, then it wouldn't
> be caught by dwarf catch/cleanup regions".

If you can make your point without any references to any C/C++ specific 
features it might be more convincing ;)

> 
> He's right.  You can't just jump to the invoke instruction, you must
> also pop any cleanups.  This is nothing to do with C++, and it has
> nothing to do with whether a language has stack-allocated objects.

What cleanups?
If the C++ front end leaves all these dead objects on the stack and 
insists they are cleaned up promptly, then it its responsibility to 
clean them up.
It shouldn't burden other front-ends.

In a purely heap allocated language without finalizers, say ML or 
haskell, there is nothing to clean-up and a simple jump will suffice.

For languages with finalizers such as Python or Java, a special 
finalizer thread can do the cleaning up lazily once the GC has collected 
the dead objects.

It does depend on the language semantics, and a lot of languages allow 
lazy finalization of objects.
> 
> Andrew.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>