[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Mark Shannon]

Andrew Haley wrote:
> Mark Shannon wrote:
>> Andrew Haley wrote:
> 
>>> 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 ;)
> 
> Well, you seemed to be claiming that cleanups were due to stack-allocated
> objects in C++.  I have shown that is not the case.

You have shown no such thing.
> 
>>> 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?
> 
> The ones pushed by pthread_cleanup_push().

pthread_cleanup_push() only exists in C/C++. It is a C library function 
declared in "pthreads.h" a C header file
There are other languages than C/C++.
And some of them are easier to use :)
> 
>> 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.
> 
> Like I said, it's nothing to do with C++, or with the C++ front end.
So give me an example than is not related to C/C++.

> 
>> 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.
> 
> [Aside: That's not quite true for Java, where unwinding releases
> locks.  This could be done by registering a handler at every site
> where a lock is acquired, but I don't think that's how it generally
> works.]
But llvm doesn't support that, so a Java front-end must insert code to 
do the unlocking. Its separate from unwinding. Why can't the C++ 
front-end insert code to do its language-specific cleanups.

> 
> Maybe there does exist a programming language that never calls (or is
> called by) programs in other programming languages and never runs in
> an environment where one of its threads may be terminated.  In that
> case, interoperability of generated code doesn't matter.  In the
> heterogeneous world of the contemporary OS I'm not sure if that's a
> common case.
The level of inter-language interoperability you are talking about is 
frankly next to impossible.
Java doesn't allow threads to be terminated precisely because of the 
sort of problems it causes.

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