[Gammaray-interest] New plugin idea: Event inspector

[Christian Gagneraud]

On 17 September 2017 at 17:10, Christian Gagneraud <chgans at gmail.com> wrote:
> On 15 September 2017 at 22:37, Christian Gagneraud <chgans at gmail.com> wrote:
>> On 15 September 2017 at 16:06, Christian Gagneraud <chgans at gmail.com> wrote:
>>> Hi there,
>>>
>>> I'm starting to think seriously about jumping into the gammara world.
>>>
>>> What I would like to get/do/contribute is a first class citizen event inspector.
>>>
>>> I won't waste your time with lot of words, so basically i would like
>>> to hook on CustomApplication::notify, CustomObject::event and
>>> CustomnObject::eventFilter, and store occurrences when some condition
>>> matches.
>>
>> context: Linux + x86(_64) + gcc
>>
>> I just had a look at the Probe, the Injector and the
>> FunctionOverwriter classes and skimmed quickly through some plugins ,
>> and there's enough interesting stuff to start playing with this idea.
>> I've already learned lot of things! ;)
>> I didn't know that since Qt-5.4, installing hooks was that easy - if
>> you don't mind depending on qtbase-private.
>> I was surprise by the "simple" approach taken by GammaRay, I was
>> expecting heavy use of SO preload instead i found a "simple is
>> beautiful" approach (simple is always a relative word).
>>
>> I think it is doable to dynamically wrap CustomApplication::notify, as
>> you can dynamically build the mangled symbol of the
>> QApplication::notify overloads, same goes with QObject::Event and
>> QObject::eventFilter ones: their signatures are well known and
>> QMetaObject provide the rest, did i miss something?
>
> Obviously i did miss something! ;)
> First FunctionOverwriter is not a misnomer, it does overwrite the
> function implementation not the symbol. So once overwritten there is
> no way to call the original implementation.
> Then, the function overwriter overwrites special Qt function, that are
> designed for this purpose, i cannot use that to overwrite arbitray C++
> symbol. Or at least not in it's current form.

Hope you don't mind my monologue... ;)

I'm reading this right [1] now, it's called "Cheating the ELF -
Subversive Dynamic Linking to Libraries".
AFAIU, he's talking about manipulation of the PLT of an ELF image.
Which is, I think, what i would like to achieve: replace a symbol with
another one of my choice, and still be able to call the original
symbol.
Now, this does not seem easy....

Chris

[1] https://grugq.github.io/docs/subversiveld.pdf

>
> I've noticed that Qt export as well QEventLoop::exec() in it's
> QtCore.dynlist, not sure what QtCore.dynlist is about, but this file
> contains the 3 "special" method mentioned above along this one.
>
> I've seen as well QInternal::registerCallback and co... again not sure
> how it could be used.
>
> I don't think that installing eventFilter on objects is the best way
> to monitor event dispatching and filtering.
>
> It would be really nice to have runtime event analysis, in the mean
> time i'll switch back to compile/link time hacks...
>
> Chris
>
>>
>> The only thing that i think would need work is the C++ object
>> wrapping, as FunctionOverwriter seems to be geared toward C, not C++.
>> Basically i need access to the C++ "this" [1] and the
>> FunctionOverwriter's trampoline code in a preloaded SO that doesn't
>> depend on Qt...
>>
>> Well, that's the theory. I will then have to find a way for this
>> preloaded SO to exec custom hooks/handlers. I don't think it should be
>> that hard but memory allocators, multi-threadings and
>> auto/self-induced events will certainly make the job harder thought...
>>
>> Now, given the high-profile of GammaRay developpers, I have the
>> feeling that you never went this path by choice (ie: not for technical
>> reasons obviously! ;)), would you accept this sort of hackish stuff in
>> GammaRay? A pre-loaded SO dedicated to Qt event profiling?
>>
>> PS: If I ever go further, i will eventually want to get that working
>> on arm32-linux too.
>>
>> Thanks,
>> Chris
>>
>> [1] https://blog.kummerlaender.eu/article/notes_on_function_interposition_in_cpp/
>>
>>>
>>> Meta-data associated with such occurences:
>>> - entry/exit timestamps
>>> - nesting level (per thread)
>>> - sender object (if one and possible to deduce)
>>> - sender thread
>>> - receiver object
>>> - receiver thread
>>> - event payload
>>> - filter result
>>> - ...
>>>
>>> The end user should be able to add/remove monitoring conditions,
>>> maybe simply based on:
>>> - sender thread
>>> - receiver object
>>> - event type
>>>
>>> The visualisation would be a tree model (for a given thread), as I am
>>> particularly interested in nesting and ordering analysis.
>>>
>>> I know i'm quite vague, but what do you guys think? Does such a tool
>>> already exists? Open source or not? Does that sound something that
>>> could be done with gammaray?
>>>
>>> Chris