[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]
marks at dcs.gla.ac.uk
Mon Jul 20 08:17:37 PDT 2009
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
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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev