[forgot to hit "reply to all" instead of just reply ...]
On 7/15/06, Dan Kegel dank@kegel.com wrote:
The right thing to do would be to promote the linux thread to be a win32 thread, but as a temporary stopgap, Thomas had the linux thread just do CreateThread and exit, hoping that the newly create Windows thread was healthy.
Well, I think calling CreateThread directly from the context of the hijacked thread would be simpler, though I understand that gets hairy as well if the hijacked thread is holding (say) the loader lock
Maybe we should look more carefully about what it takes to build a normal, healthy win32 thread from a posix thread.
This has been looked at in the past for sure, but I'm not sure if it's documented anywhere.
Well, kind of. Signals are only delivered when syscalls return, so they won't work well if the thread you pick to molest happens to not make any syscalls for a long time.
Hm, really? I haven't come across this before ... how then is it possible to debug a program that is sitting in while(1); if SIGSTOP cannot be delivered? Also we already use SIGUSR1 to suspend a thread and that has to work at any point, so maybe it might need to be changed.
You don't preserve the register state.
Really? What's ptrace(PTRACE_GETREGS, pid, NULL, regs) then, chopped liver? :-)
Oops, my mistake! Sorry Thomas, I didn't see that. If you switch EIP to a register function though you get all this for free ...
Well, if Alexandre thinks that's the way to go, that'd be fine. I thought those only fired when the thread in question performed an alertable wait condition (so says http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp ) so it didn't seem like an obvious way to go.
Right but if the thread is suspended then it's waiting, and we could maybe hack it to do an alertable wait. Though doing an alertable wait during a suspend is surely the wrong thing to do in most cases, presumably the server could easily queue an APC itself but not allow other clients to do the same.
thanks -mike