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