This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> The same issue was pointed out (albeit in passing)
> when Aldy Hernandez had submitted his __try/__finally
> patch to GCC for C.

And I responded at the time claiming that the semantics of
the two extensions are identical.

Very similar, but not identical, AFAICT:


http://msdn.microsoft.com/library/en-us/vccelng/htm/state_14.asp

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.

Of course this would tie in with integrating SEH support into GCC,
a brave attempt at which can be found at:

http://reactos.wox.org/index.php?page=gccseh

in which case my point becomes moot.


> Since the Win32 API stack does not have DW2 EH
> unwind information, the program just terminates
> when an exception is thrown (if using DW2 EH).
>
> SJLJ does not have any such problems.
>
> In fact, this seems to be a fundamental limitation
> of the DW2 EH mechanism and not just on Windows.

Yes.  Such is the price you pay for not saving all of the
registers up front when an exception is *not* thrown.

IIRC, till some time ago "-fsjlj-exceptions" used to be available that should allow such fringe cases to work albeit with a performance hit.

Otherwise DW2 EH is *way better* than SJLJ as you all
know very well and should be the default.

Does anyone know why "fsjlj-exceptions" support was
dropped and made a configure time option?


> MD_FALLBACK_FRAME_STATE_FOR looks a bit promising
> but how do we generalise it to any "foreign" caller?

Eh, MD_FALLBACK_FRAME_STATE_FOR isn't really generalizable.
You could perhaps hack it to parse SEH unwind data, but...

SEH is an SJLJ type scheme:


http://www.microsoft.com/msj/0197/Exception/Exception.aspx


Another possibility is to give up on unwind-dw2.c entirely
and write a new unwinder that uses the SEH bits in the Win32
API directly, all the time.  Then (1) you'd be able to unwind
through Windows routines and (2) there'd be no "confusion"
about the supposed "differences" in try/finally.

Possible, but it feels awful to throw away the fantastic DW2 EH...


:-(

Ranjit.

_________________________________________________________________
Dreaming of a holiday? Make it happen. http://server1.msn.co.in/sp03/switzerlandtourism/index.asp In Switzerland!



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]