public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/9539: [Windows] builtin [long/set]jmp not working properly with signals
@ 2003-02-20 8:53 ebotcazou
0 siblings, 0 replies; 3+ messages in thread
From: ebotcazou @ 2003-02-20 8:53 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, obry
Synopsis: [Windows] builtin [long/set]jmp not working properly with signals
State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Thu Feb 20 08:53:19 2003
State-Changed-Why:
Already analyzed by Danny.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9539
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c/9539: [Windows] builtin [long/set]jmp not working properly with signals
@ 2003-02-03 19:56 Pascal Obry
0 siblings, 0 replies; 3+ messages in thread
From: Pascal Obry @ 2003-02-03 19:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/9539; it has been noted by GNATS.
From: Pascal Obry <p.obry@wanadoo.fr>
To: Danny Smith <dannysmith@users.sourceforge.net>
Cc: gcc-gnats@gcc.gnu.org,
gcc-bugs@gcc.gnu.org,
nobody@gcc.gnu.org,
gcc-prs@gcc.gnu.org
Subject: Re: c/9539: [Windows] builtin [long/set]jmp not working properly with
signals
Date: Mon, 3 Feb 2003 20:46:02 +0100
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c/9539: [Windows] builtin [long/set]jmp not working properly with signals
@ 2003-02-03 10:26 Danny Smith
0 siblings, 0 replies; 3+ messages in thread
From: Danny Smith @ 2003-02-03 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/9539; it has been noted by GNATS.
From: Danny Smith <dannysmith@clear.net.nz>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, obry@gnat.com,
nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org
Cc:
Subject: Re: c/9539: [Windows] builtin [long/set]jmp not working properly with
signals
Date: Mon, 03 Feb 2003 10:18:39 +0000
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=g
cc&pr=9539
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:
/* __builtin_setjmp is passed a pointer to an array of five words (not
all will be used on all machines). It operates similarly to the C
library function of the same name, but is more efficient. Much of
the code below (and for longjmp) is copied from the handling of
non-local gotos.
NOTE: This is intended for use by GNAT and the exception handling
scheme in the compiler and will only work in the method used by
them. */
and this excerpt from extend.texi:
"GCC provides a large number of built-in functions other than the ones
mentioned above. Some of these are for internal use in the processing
of exceptions or variable-length argument lists and will not be
documented here because they may change from time to time; we do not
recommend general use of these functions."
Perhaps this disclaimer should be explicitly mention
__builtin_setjmp/longjmp as an example of a internal-use only builtin?
BTW the callback for SetUnhandledExceptionFilter should be a stdcall
function, else you risk stack corruption. GCC warns about that with:
warning: passing arg 1 of `SetUnhandledExceptionFilter' from
incompatible pointer type
Danny
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-02-20 8:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-20 8:53 c/9539: [Windows] builtin [long/set]jmp not working properly with signals ebotcazou
-- strict thread matches above, loose matches on Subject: below --
2003-02-03 19:56 Pascal Obry
2003-02-03 10:26 Danny Smith
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).