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. Corinna