From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] sigsetjmp/siglongjmp on cygwin -- problem tracked down Date: Mon, 13 Aug 2001 19:55:00 -0000 Message-id: <20010813225508.A22351@redhat.com> References: <3B785A0C.7000104@cygnus.com> <20010813193225.A10164@redhat.com> <20010813222037.A20589@redhat.com> <3B788F78.8050005@cygnus.com> X-SW-Source: 2001-08/msg00159.html 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 > #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