From kde-core-devel  Tue Nov 01 20:56:53 2011
From: =?ISO-8859-1?Q?Peter_K=FCmmel?= <syntheticpp () gmx ! net>
Date: Tue, 01 Nov 2011 20:56:53 +0000
To: kde-core-devel
Subject: Re: GammaRay - Introspection/Debugging Tool for Qt Applications
Message-Id: <4EB05D15.7010604 () gmx ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=132018114424410

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
>
>