Re: [patch] fix spurious SIGSEGV faults under Cygwin

[Brian Dessent <brian at dessent dot net>]

Christopher Faylor wrote:

> Thanks for the patch but I've been working on this too and, so far, I think
> it is possible to have a very minimal way of dealing with this problem.  I
> haven't had time to delve into it too deeply but I have been exploring this
> problem on and off for a couple of weeks.  If the situation at work calms
> down a little I may be able to finish up what I've been working on.
> 
> OTOH, if what I have is really not working then I'll take a look at what
> you've done.

Okay, no rush.  FWIW after noticing that strace was broken I tested a
version that used

 #define _CYGWIN_SIGNAL_STRING "cYgSiGw00f"
+#define _CYGWIN_FAULT_IGNORE_STRING "cYg0 faultig"
+#define _CYGWIN_FAULT_NOIGNORE_STRING "cYg0 nofaultig"

...which seems to fix the problem since the strtold() just picks up 0
after 'cYg' and strace ignores the rest.

The main problem I see with this approach is the extra call to
IsDebuggerPresent() every time a 'myfault' is created/destroyed, which
potentially could be a lot.  I'm presuming this is a relatively cheap
call so it wasn't something I worried too much about.  But then I didn't
actually try to measure it.

If it turns out that it's expensive, I was thinking that the inferior
could maintain this information in some variable, and just communicate
its location to gdb once at startup, then gdb could simply read that
variable in the process' memory before deciding whether to handle the
fault.  Or it could try to look at the SEH chain and see if a handler
residing in cygwin1.dll is setup to handle the fault, and if so just
silently pass it along.  But that seemed really complicated when there
already exists this mechanism for the process to communicate with the
debugger.

Brian