This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]