__attribute__((cleanup(function)) versus try/finally

[Andrew Haley]

Ranjit Mathew writes:
 > >  > > > The __finally block is executed in case of both "normal" C++ 
 > >exceptions
 > >  > > > as well as "faults" such as accessing a NULL pointer, dividing by 
 > >zero,
 > >  > > > etc.
 > >  > >
 > >  > >And your point is... ?  Libjava does this for dwarf2 EH on Linux.
 > >  >
 > >  > Yes, I know (http://gcc.gnu.org/java/port-signals.html).
 > >
 > >Oh no, that page is way, way out of date.  I must rewrite it.
 > >There's not even any mention of MD_FALLBACK_FRAME_STATE_FOR, which is
 > >the crucial part of the job.
 > 
 > Maybe laymen aren't supposed to be implementing MAKE_THROW_FRAME for
 > libgcj ;-), but I think it should at least be pointed out that the crucial 
 > reasons
 > the given example works *at all* are that:
 > 
 > 1. Linux does not care if the signal handler returns or not (unlike 
 > Windows).

Actually, the C standard is quite explicit about this: signal handlers
may return either by a return statement of calling longjmp().  Maybe
the Windows version of longjmp() does some magic to make this work.

 > 2. A proper MD_FALLBACK_FRAME_STATE_FOR definition for Linux/x86 

Or for any other OS, for that matter.  The trouble with doing
MD_FALLBACK_FRAME_STATE_FOR for other OSs is that it necessarily
requires knowledge of kernel data structures.

 >    ensures that unwinding works through the intervening signal
 >    handler frame when a "throw" occurs, instead of aborting the
 >    process with an uncerimonious "abnormal program termination" as
 >    would have happened otherwise.

Actually, that example was written before MD_FALLBACK_FRAME_STATE_FOR,
as was the whole page.  That's why it's so inaccurate.

Andrew.