This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/9539: [Windows] builtin [long/set]jmp not working properly withsignals
- From: Pascal Obry <p dot obry at wanadoo dot fr>
- To: Danny Smith <dannysmith at users dot sourceforge dot net>
- Cc: gcc-gnats at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org
- Date: Mon, 3 Feb 2003 20:46:02 +0100
- Subject: Re: c/9539: [Windows] builtin [long/set]jmp not working properly withsignals
- References: <000701c2cb6d$a05d0640$1490a7cb@DANNY>
Danny,
> I wouldn't expect OS signal handling (particularly the Windows flavour)
> to play nicely with __builtin_setjmp/longjmp because of this comment in
> builtins.c:
Yes I saw that. It is exactly while working on GNAT exception handling that
this bug was found. In GNAT the __builtin_setjmp/longjmp are used to implement
the exception mechanism. All this works fine in the context of exception but
we found that a signal was breaking the whole mechanism.
We have tried to find a way around that but did not succeed! There is some
"magic" done in the Microsoft longjmp code as it works just fine with signals
handler... I have found nothing on the MSDN...
Do you have any hints about what is going on here ?
> BTW the callback for SetUnhandledExceptionFilter should be a stdcall
> function, else you risk stack corruption. GCC warns about that with:
Agreed.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595