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).