Dan Kegel wrote:
On 8/5/06, Eric Pouech eric.pouech@wanadoo.fr 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: dank@lappy:~/wine-git/programs/winedbg$ grep CreateRemote *.c dank@lappy:~/wine-git/programs/winedbg$ grep VirtualAlloc *.c dank@lappy:~/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/winp...
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+