[RFC] sigsetjmp/siglongjmp on cygwin

[RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

Hi,

I would like to discuss what to do about siglongjmp/sigsetjmp. These
functions were recently added to configure.in:

2001-07-12  Mark Kettenis  <kettenis@gnu.org>

        * configure.in: Add check for sigsetjmp.

To make a long story short, I spent a lot of time trying to track this
down. The crux of it is that sigsetjmp/siglongjmp _do_ exist on cygwin,
but they are not reliable. I don't know why, but they are not.

Until the above change, cygwin used setjmp/longjmp, and this patch will
force gdb to use them again.

I'm open to better ways of dealing with this.
Keith

Possible ChangeLog
2001-08-01  Keith Seitz  <keiths@redhat.com>

	* configure.in: Don't use sigsetjmp/siglongjmp on
	cygwin, even if it is available: it doesn't work.
	* configure: Regenerate.

Possible Patch
Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.66
diff -u -p -r1.66 configure.in
--- configure.in	2001/07/12 13:48:45	1.66
+++ configure.in	2001/08/01 21:01:29
@@ -137,11 +137,16 @@ AC_FUNC_ALLOCA

 # Check if sigsetjmp is available.  Using AC_CHECK_FUNCS won't do
 # since sigsetjmp might only be defined as a macro.
+# Cygwin has sigsetjmp/siglongjmp, but it doesn't seem to work...
 AC_CACHE_CHECK([for sigsetjmp], gdb_cv_func_sigsetjmp,
 [AC_TRY_COMPILE([
 #include <setjmp.h>
 ], [sigjmp_buf env; while (! sigsetjmp (env, 1)) siglongjmp (env, 1);],
-gdb_cv_func_sigsetjmp=yes, gdb_cv_func_sigsetjmp=no)])
+[case "${host}" in
+  *cygwin*) gdb_cv_func_sigsetjmp=no ;;
+  *) gdb_cv_func_sigsetjmp=yes ;;
+esac
+], gdb_cv_func_sigsetjmp=no)])
 if test $gdb_cv_func_sigsetjmp = yes; then
   AC_DEFINE(HAVE_SIGSETJMP, 1, [Define if sigsetjmp is available. ])
 fi

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

On 2 Aug 2001, Mark Kettenis wrote:

> Keith Seitz <keiths@cygnus.com> writes:
>
> > To make a long story short, I spent a lot of time trying to track this
> > down. The crux of it is that sigsetjmp/siglongjmp _do_ exist on cygwin,
> > but they are not reliable. I don't know why, but they are not.
>
> Damn!  Any chance of fixing cygwin?

I dunno, but I'm not sure we can just go around telling people to update
cygwin -- or can we?

> > I'm open to better ways of dealing with this.
>
> Can't say I like your patch.

Me either. That's why this is an RFC and not an RFA... :-)

> [...] An alternative would be to #undef
> HAVE_SIGSETJMP in the cygwin xm.h file.  That isolates this bogosity
> nicely in a platform-specific file.

Hmmm.. This might be a better approach. I hate touching configure.in: it
makes everyone recompile all of gdb.

What say others?
Keith

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Eli Zaretskii]

On Wed, 1 Aug 2001, Keith Seitz wrote:

> > [...] An alternative would be to #undef
> > HAVE_SIGSETJMP in the cygwin xm.h file.  That isolates this bogosity
> > nicely in a platform-specific file.
> 
> Hmmm.. This might be a better approach. I hate touching configure.in: it
> makes everyone recompile all of gdb.

Or maybe #define sigsetjmp setjmp etc., again in a Cygwin-specific
header.  You can even make that define be version specific, assuming
that some future version of Cygwin solves the problem.

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> On Wed, 1 Aug 2001, Keith Seitz wrote:
> 
> 
>> > [...] An alternative would be to #undef
>> > HAVE_SIGSETJMP in the cygwin xm.h file.  That isolates this bogosity
>> > nicely in a platform-specific file.
> 
>> 
>> Hmmm.. This might be a better approach. I hate touching configure.in: it
>> makes everyone recompile all of gdb.
> 
> 
> Or maybe #define sigsetjmp setjmp etc., again in a Cygwin-specific
> header.  You can even make that define be version specific, assuming
> that some future version of Cygwin solves the problem.


Again, I'm not too warm on this.

Remember, the idea is for autoconf to perform a feature based test: is 
feature XYZ supported?  In the case of the above, the feature question 
is: does the system have a useable sigsetjmp()?  Unfortunatly, the test 
currently asks: does the system have anything looking like sigsetjmp(), 
working or not? :-)  I think Keith's original patch is the correct fix. 
  It refines the test so that, for cygwin, it reports back ``no 
sigsetjmp()'' is not there (or is broken).

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Mark Kettenis]

   Date: Thu, 02 Aug 2001 13:25:01 -0400
   From: Andrew Cagney <ac131313@cygnus.com>

   > Or maybe #define sigsetjmp setjmp etc., again in a Cygwin-specific
   > header.  You can even make that define be version specific, assuming
   > that some future version of Cygwin solves the problem.

   Again, I'm not too warm on this.

   Remember, the idea is for autoconf to perform a feature based test: is 
   feature XYZ supported?  In the case of the above, the feature question 
   is: does the system have a useable sigsetjmp()?  Unfortunatly, the test 
   currently asks: does the system have anything looking like sigsetjmp(), 
   working or not? :-)  I think Keith's original patch is the correct fix. 

Not quite...

It is very un-autoconf-like to use the host-triple to decide whether
things are broken or not.  If there is an easy way to check for the
broken sigsetjmp behaviour on cygwin, we really should do that instead
of relying on the host-triple.  However, I don't think we can :-(.

   It refines the test so that, for cygwin, it reports back ``no 
   sigsetjmp()'' is not there (or is broken).

Then it would be really great if configure reports back that sigsetjmp
is broken for cygwin.  Keith, I think you should set
gdb_cv_func_sigsetjmp to "broken" instead of "no" for cygwin.  With
that change your origional patch can go in.

Mark

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Jim Blandy]

Mark Kettenis <kettenis@wins.uva.nl> writes:
> It is very un-autoconf-like to use the host-triple to decide whether
> things are broken or not.  If there is an easy way to check for the
> broken sigsetjmp behaviour on cygwin, we really should do that instead
> of relying on the host-triple.  However, I don't think we can :-(.

I'd like to weigh in on Mark's side here.

I did the conversion of GNU Emacs from old-style configuration, with a
header file describing each host, to autoconf-style configuration.
The difference is pretty dramatic.  Updating and fixing header files
used to be a pretty constant background activity; after switching to
autoconf, it just wasn't a big deal any more.

I would always recommend adding a "does this work?" test to
configure.in over statically associating an answer with a particular
host, whether via a per-host header file, or via a case statement
switching on the host triple.  They're really not that hard to write.

Keith Seitz writes:
> I hate touching configure.in: it makes everyone recompile all of
> gdb.

My heart bleeds.  :)  The world can handle another coffee break.

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

On 13 Aug 2001, Jim Blandy wrote:

> I would always recommend adding a "does this work?" test to
> configure.in over statically associating an answer with a particular
> host, whether via a per-host header file, or via a case statement
> switching on the host triple.  They're really not that hard to write.

Would love to do this, but, unfortunately, writing a simple test to do
this is not so easy. The problem is that sigsetjmp/siglongjmp are, for
lack of a better phrase, "flakey". Ever simple testcase I come up with
works just fine, but I can get gdb to crash instantly...

:-(
Keith

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> Would love to do this, but, unfortunately, writing a simple test to do
> this is not so easy. The problem is that sigsetjmp/siglongjmp are, for
> lack of a better phrase, "flakey". Ever simple testcase I come up with
> works just fine, but I can get gdb to crash instantly...


Yes, I think that is what every one is stumped on.  Making it more 
difficult, a compile time rather than a runtime test is probably needed 
- otherwize it won't be possible to canadian cross GDB.

Perhaphs the real problem is GDB corrupting its stack?  Can you explain 
the test case or is it just ``normal use''?

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

On Mon, 13 Aug 2001, Andrew Cagney wrote:

> > Would love to do this, but, unfortunately, writing a simple test to do
> > this is not so easy. The problem is that sigsetjmp/siglongjmp are, for
> > lack of a better phrase, "flakey". Ever simple testcase I come up with
> > works just fine, but I can get gdb to crash instantly...
>
>
> Yes, I think that is what every one is stumped on.  Making it more
> difficult, a compile time rather than a runtime test is probably needed
> - otherwize it won't be possible to canadian cross GDB.
>
> Perhaphs the real problem is GDB corrupting its stack?  Can you explain
> the test case or is it just ``normal use''?

It's easy to reproduce once you have gdb built with sigsetjmp/siglongjmp.
Just boot Win98 and run gdb. Do something, ANYTHING to call
return_to_top_level. I did "info func" on gdb. When the pager was done
outputting the first page of functions, I asked it to "quit" instead of
continuing the listing. Boom! It died immediately.

Of course, the bigger problem for me is that Insight causes gdb to call
return_to_top_level all the darn time, so Insight crashes immediately. :-(

Keith

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> Yes, I think that is what every one is stumped on.  Making it more
>> difficult, a compile time rather than a runtime test is probably needed
>> - otherwize it won't be possible to canadian cross GDB.
>>
>> Perhaphs the real problem is GDB corrupting its stack?  Can you explain
>> the test case or is it just ``normal use''?
> 
> 
> It's easy to reproduce once you have gdb built with sigsetjmp/siglongjmp.
> Just boot Win98 and run gdb. Do something, ANYTHING to call
> return_to_top_level. I did "info func" on gdb. When the pager was done
> outputting the first page of functions, I asked it to "quit" instead of
> continuing the listing. Boom! It died immediately.



What about:

(gdb) maint internal-error
/home/scratch/GDB/src/gdb/maint.c:119: gdb-internal-error: internal 
maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) y

Create a core file containing the current state of GDB? (y or n) n
(gdb)

Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

On Mon, 13 Aug 2001, Andrew Cagney wrote:

> What about:
>
> (gdb) maint internal-error
> /home/scratch/GDB/src/gdb/maint.c:119: gdb-internal-error: internal
> maintenance
> An internal GDB error was detected.  This may make further
> debugging unreliable.  Continue this debugging session? (y or n) y
>
> Create a core file containing the current state of GDB? (y or n) n
> (gdb)

(gdb) maint internal-error
/keiths/ref/src/gdb/maint.c:119: gdb-internal-error: internal maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) y

Create a core file containing the current state of gdb? (y or n) n

Program received signal SIGSEGV, Segmentation fault.
0x402acf in return_to_top_level (reason=RETURN_ERROR)
    at /keiths/ref/src/gdb/top.c:347
374       (NORETURN void) SIGLONGJMP (*catch_return, (int) reason);
(top-gdb)

In a previous debugging session (using insight to reproduce this), I
verified that the contents of catch_return are exactly as sigsetjmp left
them...

Keith

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Christopher Faylor]

On Mon, Aug 13, 2001 at 04:27:53PM -0700, Keith Seitz wrote:
>On Mon, 13 Aug 2001, Andrew Cagney wrote:
>
>> What about:
>>
>> (gdb) maint internal-error
>> /home/scratch/GDB/src/gdb/maint.c:119: gdb-internal-error: internal
>> maintenance
>> An internal GDB error was detected.  This may make further
>> debugging unreliable.  Continue this debugging session? (y or n) y
>>
>> Create a core file containing the current state of GDB? (y or n) n
>> (gdb)
>
>(gdb) maint internal-error
>/keiths/ref/src/gdb/maint.c:119: gdb-internal-error: internal maintenance
>An internal GDB error was detected.  This may make further
>debugging unreliable.  Continue this debugging session? (y or n) y
>
>Create a core file containing the current state of gdb? (y or n) n
>
>Program received signal SIGSEGV, Segmentation fault.
>0x402acf in return_to_top_level (reason=RETURN_ERROR)
>    at /keiths/ref/src/gdb/top.c:347
>374       (NORETURN void) SIGLONGJMP (*catch_return, (int) reason);
>(top-gdb)
>
>In a previous debugging session (using insight to reproduce this), I
>verified that the contents of catch_return are exactly as sigsetjmp left
>them...

On inspection of cygwin's code, I don't understand how this could be a cygwin
bug.  I've been meaning to investigate this.

I'll do it right now.

In the meantime, I think that configury changes are premature.

cgf

Re: [RFC] sigsetjmp/siglongjmp on cygwin -- problem tracked down

[Andrew Cagney]

> So, with the above buggy code, we'll eventually derefernce *catch_return[36]
> when we should be dereferencing (*catch_return)[36].
> 
> I'll fix cygwin.  How do we want to fix gdb?
> 
> I could add a define in setjmp.h like this:
> 
> #define WORKING_SETJMP 1


The BSD way of doing it was:

	#include <sys/param.h>
	#if BSD >= 199506
	... was this from the last bsd release ever ...
	#endf

While it leads to pretty obscure tests (like the above) it did make it 
possible to test for anything constrained to a specific release.

It may be easier to just tweek GDB so that:

    (NORETURN void) SIGLONGJMP (*catch_return, (int) reason);

is written more robustly as:

	SIGLONGJMP ((*catch_return), ((int) reason));

If CYGWIN has this bug, chance has it that some other OS will as well. 
Hmm, Macro's are (er never mind :-).

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin -- problem tracked down

[Christopher Faylor]

On Mon, Aug 13, 2001 at 10:39:52PM -0400, Andrew Cagney wrote:
>> So, with the above buggy code, we'll eventually derefernce *catch_return[36]
>> when we should be dereferencing (*catch_return)[36].
>> 
>> I'll fix cygwin.  How do we want to fix gdb?
>> 
>> I could add a define in setjmp.h like this:
>> 
>> #define WORKING_SETJMP 1
>
>
>The BSD way of doing it was:
>
>	#include <sys/param.h>
>	#if BSD >= 199506
>	... was this from the last bsd release ever ...
>	#endf
>
>While it leads to pretty obscure tests (like the above) it did make it 
>possible to test for anything constrained to a specific release.

Doh.  Now that you mention it, Cygwin actually already has a mechanism
for this.  We bump a minor version number when there are api changes,
such as this.  Then we usually define a macro like
"CYGWIN_VERSION_SIGSEJMP_IS_OK" based on the API.  It is a little
tricky, though, since the actual header file is in newlib not cygwin.

I completely forgot about this mechanism.  In my defense, I was only the
original author of the code in cygwin and only worked on this file last
week so it was really easy to forget about it.

>It may be easier to just tweek GDB so that:
>
>    (NORETURN void) SIGLONGJMP (*catch_return, (int) reason);
>
>is written more robustly as:
>
>	SIGLONGJMP ((*catch_return), ((int) reason));
>
>If CYGWIN has this bug, chance has it that some other OS will as well. 

Good point.  I agree, this is a superior way to fix this.  Maybe we need
a comment explaining why we're doing this?  Or, since SIGLONGJMP is a
macro, we could actually hide the extra parentheses there.

>Hmm, Macro's are (er never mind :-).

Macros are great!  Yessirree.  :-)

I have to agree that this is a bad use of macros in this case.  I would
have rather implemented these as functions.  siglongjmp isn't even signal
safe now and I think it should be.

In general, I think that non-trivial macros are a bad thing in system
headers although I'm sure that I've probably introduced a couple for
cygwin (not in this case, though).

cgf

Re: [RFC] sigsetjmp/siglongjmp on cygwin -- problem tracked down

[Daniel Jacobowitz]

On Mon, Aug 13, 2001 at 10:55:08PM -0400, Christopher Faylor wrote:
> On Mon, Aug 13, 2001 at 10:39:52PM -0400, Andrew Cagney wrote:
> >> So, with the above buggy code, we'll eventually derefernce *catch_return[36]
> >> when we should be dereferencing (*catch_return)[36].
> >> 
> >> I'll fix cygwin.  How do we want to fix gdb?
> >> 
> >> I could add a define in setjmp.h like this:
> >> 
> >> #define WORKING_SETJMP 1
> >
> >
> >The BSD way of doing it was:
> >
> >	#include <sys/param.h>
> >	#if BSD >= 199506
> >	... was this from the last bsd release ever ...
> >	#endf
> >
> >While it leads to pretty obscure tests (like the above) it did make it 
> >possible to test for anything constrained to a specific release.
> 
> Doh.  Now that you mention it, Cygwin actually already has a mechanism
> for this.  We bump a minor version number when there are api changes,
> such as this.  Then we usually define a macro like
> "CYGWIN_VERSION_SIGSEJMP_IS_OK" based on the API.  It is a little
> tricky, though, since the actual header file is in newlib not cygwin.

On the other hand, it should be very straightforward to write an
autoconf test for this.  You said that the code in question looked like
env[36] instead of (env)[36];  just use an argument that would not be
valid to subscript.  env + 1[36], for instance, should generally not
compile.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

[RFA] work around sigsetjmp/siglongjmp macro problems

[Christopher Faylor]

[NOTE: reply-to set to gdb-patches]
On Mon, Aug 13, 2001 at 08:11:16PM -0700, Daniel Jacobowitz wrote:
>> Doh.  Now that you mention it, Cygwin actually already has a mechanism
>> for this.  We bump a minor version number when there are api changes,
>> such as this.  Then we usually define a macro like
>> "CYGWIN_VERSION_SIGSEJMP_IS_OK" based on the API.  It is a little
>> tricky, though, since the actual header file is in newlib not cygwin.
>
>On the other hand, it should be very straightforward to write an
>autoconf test for this.  You said that the code in question looked like
>env[36] instead of (env)[36];  just use an argument that would not be
>valid to subscript.  env + 1[36], for instance, should generally not
>compile.

Luckily, as Andrew has pointed out, there is no reason to go to this
trouble.

My proposed patch is below.  It may even be an obvious fix.

Keith, could you try this out and verify that it fixes the problem?

cgf

2001-08-13  Christopher Faylor  <cgf@cygnus.com>

	* top.c (SIGSETJMP): Protect macro argument with parentheses.
	(SIGLONGJMP): Protect macro argument with parentheses.

Index: top.c
===================================================================
RCS file: /cvs/uberbaum/gdb/top.c,v
retrieving revision 1.42
diff -p -r1.42 top.c
*** top.c	2001/08/01 18:39:23	1.42
--- top.c	2001/08/14 03:05:50
*************** NORETURN void (*error_hook) (void) ATTR_
*** 299,310 ****
     directly.  */
  #if defined(HAVE_SIGSETJMP)
  #define SIGJMP_BUF		sigjmp_buf
! #define SIGSETJMP(buf)		sigsetjmp(buf, 1)
! #define SIGLONGJMP(buf,val)	siglongjmp(buf,val)
  #else
  #define SIGJMP_BUF		jmp_buf
  #define SIGSETJMP(buf)		setjmp(buf)
! #define SIGLONGJMP(buf,val)	longjmp(buf,val)
  #endif
  
  /* Where to go for return_to_top_level.  */
--- 299,310 ----
     directly.  */
  #if defined(HAVE_SIGSETJMP)
  #define SIGJMP_BUF		sigjmp_buf
! #define SIGSETJMP(buf)		sigsetjmp((buf), 1)
! #define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))
  #else
  #define SIGJMP_BUF		jmp_buf
  #define SIGSETJMP(buf)		setjmp(buf)
! #define SIGLONGJMP(buf,val)	longjmp((buf), (val))
  #endif
  
  /* Where to go for return_to_top_level.  */

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Eli Zaretskii]

> Date: Mon, 13 Aug 2001 23:18:01 -0400
> From: Christopher Faylor <cgf@redhat.com>
>
> ! #define SIGSETJMP(buf)		sigsetjmp((buf), 1)
> ! #define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))

I suggest to add a comment here which explains why do you need parens
around the argument.

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Christopher Faylor]

On Tue, Aug 14, 2001 at 10:05:32AM +0300, Eli Zaretskii wrote:
>> Date: Mon, 13 Aug 2001 23:18:01 -0400
>> From: Christopher Faylor <cgf@redhat.com>
>>
>> ! #define SIGSETJMP(buf)		sigsetjmp((buf), 1)
>> ! #define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))
>
>I suggest to add a comment here which explains why do you need parens
>around the argument.

I considered that but, in reality, I think it was a bug that they were
missing.  It is just "good style" (tm) to parenthesize macro arguments.
I checked other macros in gdb.  Most, if not all, of them parenthesize
their arguments without comment.

I didn't see any reason to document the parenthesizing in this one case,
even though it is fixing a bug.  I thought it would be unlikely that
someone would come along later and remove the parentheses from this
and other macro arguments.

However, if the consensus is that comments are needed, then I'll add them.

cgf

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Keith Seitz]

On Mon, 13 Aug 2001, Christopher Faylor wrote:

> My proposed patch is below.  It may even be an obvious fix.
>
> Keith, could you try this out and verify that it fixes the problem?

Yep, works just fine.

Keith

> 2001-08-13  Christopher Faylor  <cgf@cygnus.com>
>
> 	* top.c (SIGSETJMP): Protect macro argument with parentheses.
> 	(SIGLONGJMP): Protect macro argument with parentheses.
>
> Index: top.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/top.c,v
> retrieving revision 1.42
> diff -p -r1.42 top.c
> *** top.c	2001/08/01 18:39:23	1.42
> --- top.c	2001/08/14 03:05:50
> *************** NORETURN void (*error_hook) (void) ATTR_
> *** 299,310 ****
>      directly.  */
>   #if defined(HAVE_SIGSETJMP)
>   #define SIGJMP_BUF		sigjmp_buf
> ! #define SIGSETJMP(buf)		sigsetjmp(buf, 1)
> ! #define SIGLONGJMP(buf,val)	siglongjmp(buf,val)
>   #else
>   #define SIGJMP_BUF		jmp_buf
>   #define SIGSETJMP(buf)		setjmp(buf)
> ! #define SIGLONGJMP(buf,val)	longjmp(buf,val)
>   #endif
>
>   /* Where to go for return_to_top_level.  */
> --- 299,310 ----
>      directly.  */
>   #if defined(HAVE_SIGSETJMP)
>   #define SIGJMP_BUF		sigjmp_buf
> ! #define SIGSETJMP(buf)		sigsetjmp((buf), 1)
> ! #define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))
>   #else
>   #define SIGJMP_BUF		jmp_buf
>   #define SIGSETJMP(buf)		setjmp(buf)
> ! #define SIGLONGJMP(buf,val)	longjmp((buf), (val))
>   #endif
>
>   /* Where to go for return_to_top_level.  */
>

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Elena Zannoni]

Keith Seitz writes:
 > On Mon, 13 Aug 2001, Christopher Faylor wrote:
 > 
 > > My proposed patch is below.  It may even be an obvious fix.
 > >
 > > Keith, could you try this out and verify that it fixes the problem?
 > 
 > Yep, works just fine.
 > 
 > Keith


Ok, check it in.  I don't think there is need for comments. Maybe in
the gdb coding style section of the gdb internal manual, we should make
this point about macro's arguments. Eli?

Elena


 > 
 > > 2001-08-13  Christopher Faylor  <cgf@cygnus.com>
 > >
 > > 	* top.c (SIGSETJMP): Protect macro argument with parentheses.
 > > 	(SIGLONGJMP): Protect macro argument with parentheses.
 > >
 > > Index: top.c
 > > ===================================================================
 > > RCS file: /cvs/uberbaum/gdb/top.c,v
 > > retrieving revision 1.42
 > > diff -p -r1.42 top.c
 > > *** top.c	2001/08/01 18:39:23	1.42
 > > --- top.c	2001/08/14 03:05:50
 > > *************** NORETURN void (*error_hook) (void) ATTR_
 > > *** 299,310 ****
 > >      directly.  */
 > >   #if defined(HAVE_SIGSETJMP)
 > >   #define SIGJMP_BUF		sigjmp_buf
 > > ! #define SIGSETJMP(buf)		sigsetjmp(buf, 1)
 > > ! #define SIGLONGJMP(buf,val)	siglongjmp(buf,val)
 > >   #else
 > >   #define SIGJMP_BUF		jmp_buf
 > >   #define SIGSETJMP(buf)		setjmp(buf)
 > > ! #define SIGLONGJMP(buf,val)	longjmp(buf,val)
 > >   #endif
 > >
 > >   /* Where to go for return_to_top_level.  */
 > > --- 299,310 ----
 > >      directly.  */
 > >   #if defined(HAVE_SIGSETJMP)
 > >   #define SIGJMP_BUF		sigjmp_buf
 > > ! #define SIGSETJMP(buf)		sigsetjmp((buf), 1)
 > > ! #define SIGLONGJMP(buf,val)	siglongjmp((buf), (val))
 > >   #else
 > >   #define SIGJMP_BUF		jmp_buf
 > >   #define SIGSETJMP(buf)		setjmp(buf)
 > > ! #define SIGLONGJMP(buf,val)	longjmp((buf), (val))
 > >   #endif
 > >
 > >   /* Where to go for return_to_top_level.  */
 > >

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Christopher Faylor]

On Tue, Aug 14, 2001 at 04:09:42PM -0400, Elena Zannoni wrote:
>Keith Seitz writes:
> > On Mon, 13 Aug 2001, Christopher Faylor wrote:
> > 
> > > My proposed patch is below.  It may even be an obvious fix.
> > >
> > > Keith, could you try this out and verify that it fixes the problem?
> > 
> > Yep, works just fine.
> > 
> > Keith
>
>
>Ok, check it in.  I don't think there is need for comments.

Done.

>Maybe in the gdb coding style section of the gdb internal manual, we
>should make this point about macro's arguments.  Eli?

How about this:

Index: gdbint.texinfo
===================================================================
RCS file: /cvs/uberbaum/gdb/doc/gdbint.texinfo,v
retrieving revision 1.34
diff -p -r1.34 gdbint.texinfo
*** gdbint.texinfo	2001/07/31 17:30:56	1.34
--- gdbint.texinfo	2001/08/14 20:07:27
*************** However, use functions with moderation. 
*** 4395,4400 ****
--- 4395,4402 ----
  are just as hard to understand as a single thousand-line function.
  
  @emph{Macros are bad, M'kay.}
+ (But if you have to use a macro, make sure that the macro arguments are
+ protected with parentheses.)
  
  @cindex types
  
cgf

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Eli Zaretskii]

> Date: Tue, 14 Aug 2001 16:08:13 -0400
> From: Christopher Faylor <cgf@redhat.com>
> 
> >Maybe in the gdb coding style section of the gdb internal manual, we
> >should make this point about macro's arguments.  Eli?
> 
> How about this:

Approved.

> Index: gdbint.texinfo
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/doc/gdbint.texinfo,v
> retrieving revision 1.34
> diff -p -r1.34 gdbint.texinfo
> *** gdbint.texinfo	2001/07/31 17:30:56	1.34
> --- gdbint.texinfo	2001/08/14 20:07:27
> *************** However, use functions with moderation. 
> *** 4395,4400 ****
> --- 4395,4402 ----
>   are just as hard to understand as a single thousand-line function.
>   
>   @emph{Macros are bad, M'kay.}
> + (But if you have to use a macro, make sure that the macro arguments are
> + protected with parentheses.)
>   
>   @cindex types
>   
> cgf
> 

Re: [RFA] work around sigsetjmp/siglongjmp macro problems

[Eli Zaretskii]

> From: Elena Zannoni <ezannoni@cygnus.com>
> Date: Tue, 14 Aug 2001 16:09:42 -0400
> 
> Maybe in
> the gdb coding style section of the gdb internal manual, we should make
> this point about macro's arguments. Eli?

Fine with me.

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> Program received signal SIGSEGV, Segmentation fault.
> 0x402acf in return_to_top_level (reason=RETURN_ERROR)
>     at /keiths/ref/src/gdb/top.c:347
> 374       (NORETURN void) SIGLONGJMP (*catch_return, (int) reason);
> (top-gdb)
> 
> In a previous debugging session (using insight to reproduce this), I
> verified that the contents of catch_return are exactly as sigsetjmp left
> them...


So hopefully you're seeing:

PASS: gdb.base/maint.exp: maint internal-error


fail.  If not, I've got a testsuite bug.

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Keith Seitz]

On Mon, 13 Aug 2001, Andrew Cagney wrote:

> So hopefully you're seeing:
>
> PASS: gdb.base/maint.exp: maint internal-error

Yeah, we see that and a few others, too, of course. Doesn't something like
"maint print psymbols" call error ()? We crash there. All the rest of the
tests in this file timeout.

Either we've got a mem corruption or sigsetjmp/siglongjmp don't work
reliably on cygwin (on Win98).

Keith

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Eli Zaretskii]

> Date: Thu, 02 Aug 2001 13:25:01 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Remember, the idea is for autoconf to perform a feature based test: is 
> feature XYZ supported?  In the case of the above, the feature question 
> is: does the system have a useable sigsetjmp()?  Unfortunatly, the test 
> currently asks: does the system have anything looking like sigsetjmp(), 
> working or not? :-)  I think Keith's original patch is the correct fix. 
>   It refines the test so that, for cygwin, it reports back ``no 
> sigsetjmp()'' is not there (or is broken).

Intentionally failing an Autoconf test is not my idea of using
Autoconf correctly ;-)  If all Cygwin wants is to fail that test
unconditionally, they could simply supply a config.site file which
sets the appropriate Autoconf variable (ac_cv_func_sigsetjmp, IIRC),
and not bother the GDB distribution at all.  After all, the same bug
will bite Cygwin in any other package, right?

Moreover, this problem will most probably be fixed in some future
version of Cygwin, at which point someone will have to make that test
know about specific Cygwin versions etc.  IMHO, if we must have such
an ugliness, it should go into a system-specific header.

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> 
> Intentionally failing an Autoconf test is not my idea of using
> Autoconf correctly  [;-)] If all Cygwin wants is to fail that test
> unconditionally, they could simply supply a config.site file which
> sets the appropriate Autoconf variable (ac_cv_func_sigsetjmp, IIRC),
> and not bother the GDB distribution at all.  After all, the same bug
> will bite Cygwin in any other package, right?
> 
> Moreover, this problem will most probably be fixed in some future
> version of Cygwin, at which point someone will have to make that test
> know about specific Cygwin versions etc.  IMHO, if we must have such
> an ugliness, it should go into a system-specific header.


Ah, you're trying to hide the ugliness (xm-*.h) while I'm trying to 
localize it (a single configure.in sigsetjmp test that contains all the 
details).

I'm going to consult an expert on this one.

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> Can't say I like your patch.  An alternative would be to #undef
> HAVE_SIGSETJMP in the cygwin xm.h file.  That isolates this bogosity
> nicely in a platform-specific file.  Perhaps some other folks have an
> opinion on this.  If you don't hear anything, feel free to choose a
> hack.


I'm not so warm on the idea of putting something in an xm.h file.  I 
think the *SETJMP test, hacks, warts, and all should be localized.

	Andrew

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Christopher Faylor]

On Wed, Aug 01, 2001 at 07:16:43PM -0400, Andrew Cagney wrote:
>
>> Can't say I like your patch.  An alternative would be to #undef
>> HAVE_SIGSETJMP in the cygwin xm.h file.  That isolates this bogosity
>> nicely in a platform-specific file.  Perhaps some other folks have an
>> opinion on this.  If you don't hear anything, feel free to choose a
>> hack.
>
>
>I'm not so warm on the idea of putting something in an xm.h file.  I 
>think the *SETJMP test, hacks, warts, and all should be localized.

How can we test for sigsetjmp working or not working in a cross-build
environment, though.

I have changed opinions on whether sigsetjmp should work in cygwin about
five times today.  After spending some time looking at the code, I have
to confess that it seems like it should work ok to me.  That's my
current opinion, anyway.

I'd like to understand the kind of problems that Keith is seeing.  Maybe
there is something that can be done to the sigsetjmp/siglongjmp macros
to fix this problem in gdb so that we don't have to say "upgrade cygwin".

I'm very interested in fixing cygwin, though, of course.

cgf

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

Ben,

Since you know a thing or two about autoconf 
( http://sources.redhat.com/autobook/ ;-) would you mind giving an 
opinion on the below.

The full thread is at:

http://sources.redhat.com/ml/gdb-patches/2001-08/msg00012.html

	Andrew


> Hi,
> 
> I would like to discuss what to do about siglongjmp/sigsetjmp. These
> functions were recently added to configure.in:
> 
> 2001-07-12  Mark Kettenis  <kettenis@gnu.org>
> 
> * configure.in: Add check for sigsetjmp.
> 
> To make a long story short, I spent a lot of time trying to track this
> down. The crux of it is that sigsetjmp/siglongjmp _do_ exist on cygwin,
> but they are not reliable. I don't know why, but they are not.
> 
> Until the above change, cygwin used setjmp/longjmp, and this patch will
> force gdb to use them again.
> 
> I'm open to better ways of dealing with this.
> Keith
> 
> Possible ChangeLog
> 2001-08-01  Keith Seitz  <keiths@redhat.com>
> 
> * configure.in: Don't use sigsetjmp/siglongjmp on
> 	cygwin, even if it is available: it doesn't work.
> 	* configure: Regenerate.
> 
> Possible Patch
> Index: configure.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/configure.in,v
> retrieving revision 1.66
> diff -u -p -r1.66 configure.in
> --- configure.in	2001/07/12 13:48:45	1.66
> +++ configure.in	2001/08/01 21:01:29
> @@ -137,11 +137,16 @@ AC_FUNC_ALLOCA
> 
>  # Check if sigsetjmp is available.  Using AC_CHECK_FUNCS won't do
>  # since sigsetjmp might only be defined as a macro.
> +# Cygwin has sigsetjmp/siglongjmp, but it doesn't seem to work...
>  AC_CACHE_CHECK([for sigsetjmp], gdb_cv_func_sigsetjmp,
>  [AC_TRY_COMPILE([
>  #include <setjmp.h>
> ], [sigjmp_buf env; while (! sigsetjmp (env, 1)) siglongjmp (env, 1);],
> -gdb_cv_func_sigsetjmp=yes, gdb_cv_func_sigsetjmp=no)])
> +[case "${host}" in
> +  *cygwin*) gdb_cv_func_sigsetjmp=no ;;
> +  *) gdb_cv_func_sigsetjmp=yes ;;
> +esac
> +], gdb_cv_func_sigsetjmp=no)])
>  if test $gdb_cv_func_sigsetjmp = yes; then
>    AC_DEFINE(HAVE_SIGSETJMP, 1, [Define if sigsetjmp is available. ])
>  fi
> 
> 
> 
> 

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Ben Elliston]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

  Andrew> Since you know a thing or two about autoconf 
  Andrew> ( http://sources.redhat.com/autobook/ ;-) would you mind giving an 
  Andrew> opinion on the below.

  Andrew> The full thread is at:
  Andrew> http://sources.redhat.com/ml/gdb-patches/2001-08/msg00012.html

I can see the arguments from both sides -- localise the warts to
configure.in or push them out into the platform-specific file.

One must keep in mind the traditional approach used by Autoconf for
situations like this: write a test that *detects* whether
sig{set,long}jmp are broken.

The current proposals suffer the problem that GDB and Cygwin versions
will have to follow in lock-step because GDB's configury will assume
that sig{set,long}jmp is either present or absent for Cygwin hosts.
This will not be true once (if?) Cygwin is fixed and there are two
"strains" :-) out there -- those that are fixed and those that are
not.

Ben

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Eli Zaretskii]

> From: Ben Elliston <bje@redhat.com>
> Date: Mon, 13 Aug 2001 08:47:41 +1000 (EST)
> 
> The current proposals suffer the problem that GDB and Cygwin versions
> will have to follow in lock-step because GDB's configury will assume
> that sig{set,long}jmp is either present or absent for Cygwin hosts.
> This will not be true once (if?) Cygwin is fixed and there are two
> "strains" :-) out there -- those that are fixed and those that are
> not.

I suggested to put the work-around into config.site, precisely to
solve this.  Assuming such a config.site is made part of the core
Cygwin distribution, whenever sigsetjmp starts working, config.site
should be updated.  So a user which upgrades to a newer version of
Cygwin has this issue magically taken care of during the upgrade.

Re: [RFC] sigsetjmp/siglongjmp on cygwin

[Andrew Cagney]

> 
> I suggested to put the work-around into config.site, precisely to
> solve this.  Assuming such a config.site is made part of the core
> Cygwin distribution, whenever sigsetjmp starts working, config.site
> should be updated.  So a user which upgrades to a newer version of
> Cygwin has this issue magically taken care of during the upgrade.


Eli, can you expand a little.  I'm not sure what would happen if a 
current GDB was configured/built on an old cygwin which didn't have the 
config.site file.

	Andrew