As we all know, gdb isn't very compatible with wine, since gdb makes so many assumptions about the operating environment that isn't true in wine. But lately it occurred to me that perhaps it's possible to use gdb's remote debugging features to solve these issues. So recently, I've been secretly experimenting with writing gdb-server code in the wineserver. It goes something like this...
./configure --enable-remote-gdb [...blah...]
$ wine stuff gdb socket ready at: target remote localhost:1234
$ gdb wine (gdb) target remote localhost:1234
and you're currently able to look at registers, backtrace, list all the threads, change thread, and read process memory... neato. But its usefulness might be quite limited since gdb doesn't know about the dynamically-loaded dlls so it doesn't automatically load their symbols... does anyone have ideas on how to solve that? It doesn't appear that the standard remote protocol have a command to tell gdb, and I don't know how gdb ordinarily does it.
I've pondered making wine generate a file full of "add-symbol-file" commands or something that could be executed by gdb, but I don't know how to do that cleanly... preferably hacks for loading symbols should be transparent to the developer, and new symbols loaded automatically after new dlls are loaded. Hmm...
I've pondered making wine generate a file full of "add-symbol-file" commands or something that could be executed by gdb, but I don't know how to do that cleanly... preferably hacks for loading symbols should be transparent to the developer, and new symbols loaded automatically after new dlls are loaded. Hmm...
is the configuration variable 'auto-solib-add' set to 0 or 1 after switching to the remote mode ? if this doens't help, you could also try to set stop-on-solib-events to 1 it won't directly help for loading symbol, but it's the right place for hooking shared lib symbol loading
HTH
A+
-
eric pouech -
Ove Kaaven