On 26/01/2024 11:52, Corinna Vinschen wrote:
On Jan 26 12:12, Corinna Vinschen wrote:
On Jan 25 20:03, Jon Turney wrote:
On 25/01/2024 18:21, Corinna Vinschen wrote:
On Jan 25 14:50, Jon Turney wrote:
On 24/01/2024 14:39, Corinna Vinschen wrote:
On Jan 24 13:28, Jon Turney wrote:
On 23/01/2024 14:29, Corinna Vinschen wrote:
On Jan 23 14:20, Jon Turney wrote:
[...]
So this situation with a JIT debugger is even stranger than my emendations
to the documentation say.
Because we're hitting try_to_debug() in exception::handle(), which has some
code to replay the exception via ExceptionContinueExecution (which I guess
the debugger will catch as a first-chance) (and goes into a mode where it
ignores the next half-million exceptions... no idea what that's about!)
That's not the same as signal_exit() with a coredumping signal (haven't
checked if those are all generated from exceptions, but seems probable, so
the try_to_debug() there maybe isn't doing anything?), where we're going to
exit thereafter.
try_to_debug() is only calling IsDebuggerPresent() as test, and that's
nothing but a flag in the PEB which is set by the OS after a debugger
attached to the process. So the test is by definition extremely
flaky, if the debugger is connecting and disconnecting, as you
already pointed out.
I'm wondering if we can't define our own way to attach to a process,
allowing to "WaitForDebugger" as long as the debugger is a Cygwin
debugger. If we define a matching function (along the lines of
prctl(2) on Linux), we could change our debuggers, core dumpers
and stracers to call this attach function.
The idea would be to define some shared mutex object, the inferior
waits for and the debugger releases after having attached.
Is there really any need to support non-Cygwin debuggers?
idk
I think something like that used to exist a long time ago, see commit
8abeff1ead5f3824c70111bc0ff74ff835dafa55
Yeah, just, as was the default at the time, without any trace of a
*rational* why it has been removed. Also, it was too simple anyway.
First, if we want to support WIndows debugger, the inferior has to check
if the debugger is a Cygwin or native debugger. If a native debugger,
just stick to what we have today. Otherwise:
- Create a named mutex with a reproducible name (no need to use
the name as parameter) and immediately grab it.
- Call CreateProcess to start the debugger with CREATE_SUSPENDED
flag.
- Create a HANDLE array with the mutex and the process HANDLE.
On second thought, it might be a good idea to make this
interruptible as well, but given this is called from the
exception handler this may have weird results...
- Call ResumeThread on the primary debugger thread.
- Call WFMO with timeout.
Later on, the debugger either fails and exits or it calls
ReleaseMutex after having attached to the process.
- WFMO returns
- If the mutex has triggered, we're being debugged (but check
IsDebuggerPresent() just to be sure)
- If the process has triggered, the debugger exited
- If the timeout triggers... oh well.
This seems like quite a lot of work, for very marginal benefit.
And doing lots of complex work inside the process when we're in the
middle of handling a SEGV seems like asking for trouble.
I think I'll leave this alone for the moment, and we can see what (if
any) problems surface.
