--- Begin Message ---
Dne 03/27/06 v 17:16:50 (+0200), Alexandre Julliard napsal(a):
> The thing is that all of this is necessary because you want to handle
> a SIGTRAP sent with kill(). But obviously no Windows application is
> going to send us a SIGTRAP; the only way this will happen is when we
> do it ourselves in DebugBreakProcess, and there's nothing that says
> that we can't use a different mechanism here if it works better. I'd
> say that somehow reusing the existing SIGUSR1 support is probably a
> better choice.
Almost right. If I disregard platforms where TRAP_sig is not defined,
which currently is only svr4/SCO/_sun (not really sure what all
operating systems are covered by that) and only if it does not define
the TRAPNO constant.
So, basically I think you're right.
Now, I've made some experiments WRT DebugBreakProcess(), and the
result is that the current Wine's behavior is completely different
from the native. Wine generates an EXCEPTION_BREAKPOINT in the main
thread of the process, while what I see when I debug a process in
Windows XP is this:
Process ID: 0000088C, Thread ID: 0000080C
Debug exception at 7C901230
Exception code: 80000003 (STATUS_BREAKPOINT)
<DebugBreakProcess() called on Process ID 88C>
Process ID: 0000088C, Thread ID: 00000B40
Thread created
Process ID: 0000088C, Thread ID: 00000B40
Debug exception at 7C901230
Exception code: 80000003 (STATUS_BREAKPOINT)
Process ID: 0000088C, Thread ID: 00000B40
Thread exited
Process ID: 0000088C, Thread ID: 0000080C
Child process exited
That means that Windows XP creates a new thread in the given process
and breaks it at DbgBreak().
Does this mean that we may avoid sending SIGTRAP altogether?
Petr Tesarik
--- End Message ---
