ptrace uses SIGSTOP on the child process, so it boils down to the first item in the listPossible ideas:
- implement suspend/resume in processes without any specific code. We dropped that long ago for stability issues (and race condition removal as well)
- cheat for context reading in server while suspended. it will require some surgery (getting whether we are in the condition of this program, getting back to the signal handler, getting the signal context from the stack, grab the real EIP from it). Doable, but very hard to maintain (code in server, will depend on how signal handlers are written in ntdll, code will be CPU specific...)
- storing context in server while entering USR1 signal handler (to be done without races, which will require some more work, as the server doesn't synchronize with the USR1 handler)
Nice can of worms :-/
Why can't we have the server ptrace the process to suspend it like gdb would? I suppose the answer must be obvious for it not to be included on the list but I don't know enough to figure it out.
++
