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. Ciao, Duncan.
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.
Hi Andrew,> 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.cleanups are turned into invoke + (cleanup code) + _Unwind_Resume by llvm-gcc. Ciao, Duncan.