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-jul...@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 >
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
