[Gammaray-interest] New plugin idea: Event inspector

[Christian Gagneraud]

On 19 September 2017 at 22:05, Milian Wolff <milian.wolff at kdab.com> wrote:
> On Dienstag, 19. September 2017 11:45:01 CEST Christian Gagneraud wrote:
>> On 19 September 2017 at 21:17, Milian Wolff <milian.wolff at kdab.com> wrote:
>> > On Dienstag, 19. September 2017 11:11:45 CEST Christian Gagneraud wrote:
>> >> On 19 September 2017 at 20:46, Milian Wolff <milian.wolff at kdab.com>
> wrote:
>> >> > On Dienstag, 19. September 2017 10:39:45 CEST Christian Gagneraud
> wrote:
>> >> >> On 19 September 2017 at 17:11, Christian Gagneraud <chgans at gmail.com>
>> >
>> > wrote:
>> >> >> > On 18 September 2017 at 14:52, Christian Gagneraud
>> >> >> > <chgans at gmail.com>
>> >> >
>> >> > wrote:
>> >> >> >> On 18 September 2017 at 08:25, Milian Wolff <milian.wolff at kdab.com>
>> >> >> >> wrote:
>> >> >> >> [...]
>> >> >> >>
>> >> >> >>>> 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....
>> >> >> >>>
>> >> >> >>> You can have a look at the heaptrack injector code, which does
>> >> >> >>> just
>> >> >> >>> that.
>> >> >> >>
>> >> >> >> Yes, it is very interesting indeed, thanks for the pointer!
>> >> >> >
>> >> >> > Using this technique i was able to subsitute Qt's dynamic symbols
>> >> >> > (eg,
>> >> >> > qt_startup_hook) in a simple Qt application.
>> >> >> > And i now understand what this QtCore.dyn file is all about! ;)
>> >> >> >
>> >> >> > Using the Loadable program segment, i can as well wrap any Qt
>> >> >> > function
>> >> >> > used by the program (QObject::EventFilter, ...).
>> >> >>
>> >> >> Hi Milian,
>> >> >>
>> >> >> This makes me think that heaptrack doesn't track memory related
>> >> >> symbols directly imported by the program itself. It does track only
>> >> >> malloc/free made by loaded shared objects.... Am I missing something?
>> >> >>
>> >> >> Due to
>> >> >> https://github.com/KDE/heaptrack/blob/master/src/track/heaptrack_injec
>> >> >> t.c
>> >> >> pp
>> >> >> #L269
>> >> >
>> >> > What is a "malloc/free symbol directly imported by the program itself"?
>> >>
>> >> I mean "all memory related symbols" that heaptrack needs to track to
>> >> be able to fulfill its job.
>> >>
>> >> Maybe i misunderstood the goal of heaptrack.
>> >>
>> >> I started with a copy/paste of your code (see [1] below about
>> >> copy/pasting open source code), and then added another if in the
>> >> "program header type" check , one that would - I think - capture
>> >> dynamic symbols in a non dynamic object such as an ELF program file.
>> >> Basically I have the feeling that one has to check for PT_LOAD as well.
>> >> My dl_iterate_phdr always start with info->dlpi_name == "", and this
>> >> unnamed PT_LOAD program header contains dynamic symbols embedded into
>> >> the ELF program file itself.
>> >>
>> >> So if i understand correctly (and I might be wrong), heaptrack install
>> >> hooks only on dynamic symbols found in dynamic ELF object (SOlibs),
>> >> not on dynamic symbols found in "PT_LOAD"'able ELF objects such as
>> >> program files.
>> >
>> > Can you give an example of when that would apply? This is a serious
>> > question.
>> Yes, thanks for asking, it was stimulating! ;)
>>
>> But the answer is unfortunately very simple:
>> I'm running the code in the host program not in an LD_PRELOAD object!
>> So i think that in my case dl_iterate_phdr gives me access to the
>> just-loaded ELF file: the executable, which can contains itself
>> contains dynamic symbols such as malloc or free like in:
>>
>> int main(int argc, charr **argv)
>> {
>>    stuff = new Stuff()
>>    return 0;
>> }
>>
>> The ELF program file have it's own dynamic symbol table too, this call
>> to "new" will point to a non-heaptrack-tracked symbols.
>>
>> Bummer i'm disappointed by my own answer! ;)
>
> I will have to write a unit test to check whether that is really happening or
> not. A quick look at a binary like the above in elf-dissector shows a .plt
> entry for _Znam at got which will eventually call malloc internally so I think
> that should work fine.

I haven't come across "_Znam at got " yet, so i cannot comment.
But I will keep an eye, for sure! ;)

What is this thing suppose to be/do? A across-shared-objects shared
symbol cache? Lol!

Chris

>
> Cheers
>
> --
> Milian Wolff | milian.wolff at kdab.com | Senior Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
>
>