On 01.11.2011 08:58, Volker Krause wrote:
I've also tried to attach to console apps without success.
Then I realized that you use the hijacked process to show
the GammaRay mainwindow which is not possible in a
QCoreApplication executable.
So I wonder how difficult it would be to run GammaRay in a
different process? Then an IPC mechanism is needed for all
the information. Would this be fast enough? Do you plan
to add this in future?
I'd love to have that, for console apps, remote debugging on an embedded
system, and for less interference with the debugged process :)
Couldn't you reuse some IPC parts from KDAB's canceled test tool ;)
You can probably get a large amount of the features by having some kind of
network transparent QAbstractItemModel adapter. But some feature need direct
memory access, like rendering of a second QGraphicsScene view, unless you want
to send pixmaps over IPC.
Sounds manageable.
Is there a single point where all the information of
the target process goes through or is it all over the place?
I assume at least each plugin pulls information by itself.
Most of it goes through probe.cpp and the object models provided by it,
however all the plug-ins access raw QObject pointers they retrieve from those
models (and thus are bound to the same process).
OK, but when the plugins also support ipc, it should be possible to remote
debug/monitor for instance a state machine.
Peter
And how much does the current code depend on x86/64?
Would it be hard to support PPC?
There are two injectors that are very architecture specific ("windll" on
Windows/MSVC and "preload" on Mac), they assume a specific layout in memory
and rewrite assembly code to intercept function calls.
All other injectors should be architecture independent ("preload" on Linux,
"gdb" on any Unix and "style" everywhere), but I don't think they have been
tested yet on non-x86 either.
Probably something I should document in the wiki...
regards
Volker
