Petr Tesarik hat@tesarici.cz writes:
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?
Creating a new thread is probably even harder, but yes we can certainly avoid SIGTRAP. One possible way is to use SIGUSR1 to change the thread context to simulate a call to DbgBreakPoint.
On 06/03/27 at 18:19:44 (+0200), Alexandre Julliard wrote:
Petr Tesarik hat@tesarici.cz writes:
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?
Creating a new thread is probably even harder, but yes we can certainly avoid SIGTRAP. One possible way is to use SIGUSR1 to change the thread context to simulate a call to DbgBreakPoint.
I'm afraid one day we'll have to provide a way to create threads in other processes (this functionality is already missing from RtlCreateUserThread), but I guess this is not a current issue.
That means that for the time being, we could write the DbgBreakPoint() hack and add a FIXME to the code that in fact a thread should have been created. You know, the trouble is that under Windows XP, you would call GetThreadContext() on the original thread (not the newly created one) and get the correct register values (including EIP), but this way you get the EIP of DbgBreakPoint(). Or, do I miss something?
Anyway, I'm not familiar enough with the Wine protocol to write such code, not at least without much help from you. So, should I try it, or is it easy enough for you to code it yourself?
Petr Tesarik
Petr Tesarik hat@tesarici.cz writes:
Anyway, I'm not familiar enough with the Wine protocol to write such code, not at least without much help from you. So, should I try it, or is it easy enough for you to code it yourself?
Well, it's not a trivial fix, I don't think I'll have time to work on that in the near future, so you'll probably have to do it yourself...
-
Alexandre Julliard -
Petr Tesarik