[lttng-dev] "Hands-free" tracepoints using LD_PRELOAD

Brian Rossa br at f0cal.com
Wed Jan 23 19:20:16 EST 2019


Jonathan,

Responses below:

AFAIK, lttng does not have an equivalent.
>

I believe my code could significantly reduce the need for hand-writing the
tracepoints. But I won't likely take on a port to LTTng immediately, as a
"vanilla" interposition approach seems to be meeting my requirements.


> > Step #2 is particularly problematic due to
> > ambiguities in the mangling grammar, and will need support going forward
> to
> > generalize well.
>
> What is the status of this step in your project?
>

I demangle the symbol name using c++filt and then use regex to extract the
list of argument types. Using something like ItaniumPartialDemangler would
be better.


> What are the problems that make your implementation "error-pone"?
>

Use of regex as above.


> Would you mind linking us to said project so we can have a look?
>

It's a project for my employer, and I would need to keep the source closed
until I can get an OK. A signal of interest from LTTng would be helpful
there. In the meantime, I think it would be fine to share as read-only with
the LTTng maintainers if someone wants to send me a Github username.


> I would be interested in seeing at first lttng tracepoint used as Francis
> demonstrated and see from there were this project can go.
>
...

> > I would be happy to contribute some or all of my implementation if it's
> > something that the LTTng community would be interested in supporting and
> > extending.
>
> We are clearly open for discussion and helping you improve the project. I
> am not
> so sure on supporting and extending it. Others might have a different
> opinion.
>

Sounds good. Looking forward to connecting via personal email.

Cheers!
~br


On Tue, Jan 22, 2019 at 2:17 PM Jonathan Rajotte-Julien <
jonathan.rajotte-julien at efficios.com> wrote:

> Hi Brian,
>
> On Tue, Jan 22, 2019 at 01:30:23PM -0500, Brian Rossa wrote:
> >    4. Boilerplate that does the typical `log(...); auto return_val =
> >    dlsym(...); log(...); return return_val;` gets generated.
>
> As proposed by Francis, this is when you need to "generate" a corresponding
> tracepoint definition and call the tracepoint() call with the appropriate
> arguments.
>
> As Francis demonstrated we do not see any reason for lttng-ust not to work
> here
> given that you compile the libshim object correctly.
>
> >    5. `log(...)` is a thin interface to spdlog
> >    <https://github.com/gabime/spdlog> that handles `__attribute__`-based
> >    setup and teardown of a logger.
> >
> > So at the end of the day, the shim developer provides:
> >
> >    - The whitelist of mangled names
> >    - Implementations of struct "wrappers" that provide custom ostream
> >    operators
> >    - A map between type names and wrapper names
> >
> > The machinery here seems fairly general-purpose, but I don't presume to
> be
> > an expert. My implementation is somewhat error-prone, and my main hope in
> > reaching out to the mailing list was that LTTng already had some of these
> > steps better-implemented.
>
> AFAIK, lttng does not have an equivalent.
>
> > Step #2 is particularly problematic due to
> > ambiguities in the mangling grammar, and will need support going forward
> to
> > generalize well.
>
> What is the status of this step in your project?
>
> What are the problems that make your implementation "error-pone"?
>
> Would you mind linking us to said project so we can have a look?
>
> I would be interested in seeing at first lttng tracepoint used as Francis
> demonstrated and see from there were this project can go.
>
> >
> > I would be happy to contribute some or all of my implementation if it's
> > something that the LTTng community would be interested in supporting and
> > extending.
>
> We are clearly open for discussion and helping you improve the project. I
> am not
> so sure on supporting and extending it. Others might have a different
> opinion.
>
>
> Cheers
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20190123/1168c770/attachment.html>


More information about the lttng-dev mailing list