[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Andrew Haley]

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.

>> 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().

> 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.

> 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.]

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.

Andrew.