Dan Kegel wrote:
On 8/5/06, Eric Pouech <[EMAIL PROTECTED]> wrote:
>> Still, doing that stuff in APCs is a step in the right direction, you
>> just need to make sure you can safely run these APCs from the SIGUSR1
>> handler.
>
> Do we have to verify that now, or can that wait until we want
> to add support for debuggers?
Most of the *serious* debuggers I know of make use of remote virtual
functions. This includes WineDbg, WinDbg (the MS one)...
- WinDbg (the MS debugger)
Installer doesn't work:
http://bugs.winehq.org/show_bug.cgi?id=5866
(not a showstopper, but does make it harder to test with)
- WineDbg
Where? I just looked:
[EMAIL PROTECTED]:~/wine-git/programs/winedbg$ grep CreateRemote *.c
[EMAIL PROTECTED]:~/wine-git/programs/winedbg$ grep VirtualAlloc *.c
[EMAIL PROTECTED]:~/wine-git/programs/winedbg$
- gdb (when compiled on Windows)
I just peeked, and vanilla gdb-6.4 doesn't contain the string
CreateRemoteThread.
Some old version of 'gdb-next' did, though, but the only mention of it
I can find is here:
http://darwinsource.opendarwin.org/DevToolsDec2001/gdb-203/src/gdb-next/winpdo-nat.c
Got a place one can grab working sources + binary for a gdb that does
use CreateRemoteThread?
- Dan
I was talking (at least) about VirtualQueryEx, which should be also
implemented. All the debuggers use it for memory inspection.
Some of the debuggers use VirtualAllocEx for some nice features (like
calling a function in the debuggee), and they use the created space to
push some values to be used for those specific functions (and also
inject code the same way).
A+
