[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Andrew Haley]

Duncan Sands wrote:
> Hi Mark,
> 
>> So who is responsible for (as stated under the invoke description in the 
>> language reference) "ensure that proper cleanup is performed in the case 
>> of either a longjmp or a thrown exception"?
> 
> the unwinder (however it works) needs to stop at each invoke and run
> the code in the unwind block of the invoke.  I think it is important
> that the default method of code generation for the unwind and invoke
> instructions should interact correctly with code compiled with gcc.
> This means that the default needs to make use of dwarf unwinding.  It
> does not prevent having multiple code generation implementations, eg
> done using some kind of setjmp/longjmp implementation of unwind/invoke.
> Code created using other implementations will only work correctly if the
> entire executable, or at least the bits doing exception handling, are
> all built with the same compiler/codegen options, but that's ok if it's
> not the default.
> 
>> Is it entirely the front-end or is dwarf unwinding doing some extra work 
>> (other than a few unecessary register restores), like restoring signals,
>> and calling pthread cleanup routines?
> 
> The front-end needs to ensure that there is an appropriate invoke that
> runs the pthread cleanup routines in the unwind block.
> 
>> In other words does the dwarf unwinder do nothing other than unwind,
>> and was all that stuff about pthread_cleanup_pop() actions just a 
>> red-herring?
> 
> I think it was a red-herring, but I don't know anything about
> pthread_cleanup_pop.

For avoidance of doubt:

pthread_cleanup_pop() is nothing special, it's just an example of a
cleanup handler.  Cleanups are very similar to exception handlers, but
with one small difference: they do some work and then call
_Unwind_Resume() which continues unwinding.  The unwinder itself
doesn't know anything about pthread cleanups, it just executes
whatever is at the landing pad.

Andrew.