<div dir="ltr"><div>Jonathan,</div><div><br></div><div>Responses below:<br></div><div></div><div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
AFAIK, lttng does not have an equivalent.<br></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Step #2 is particularly problematic due to<br>
> ambiguities in the mangling grammar, and will need support going forward to<br>
> generalize well.<br>
<br>
What is the status of this step in your project?<br></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What are the problems that make your implementation "error-pone"?<br></blockquote><div><br></div><div>Use of regex as above.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would you mind linking us to said project so we can have a look?<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would be interested in seeing at first lttng tracepoint used as Francis<br>
demonstrated and see from there were this project can go.<br></blockquote><div>...<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I would be happy to contribute some or all of my implementation if it's<br>
> something that the LTTng community would be interested in supporting and<br>
> extending.<br>
<br>
We are clearly open for discussion and helping you improve the project. I am not<br>
so sure on supporting and extending it. Others might have a different opinion.<br>
</blockquote></div></div><div><br></div><div>Sounds good. Looking forward to connecting via personal email.</div><div><br></div><div>Cheers!</div><div>~br<br></div><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 22, 2019 at 2:17 PM Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com">jonathan.rajotte-julien@efficios.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
On Tue, Jan 22, 2019 at 01:30:23PM -0500, Brian Rossa wrote:<br>
> 4. Boilerplate that does the typical `log(...); auto return_val =<br>
> dlsym(...); log(...); return return_val;` gets generated.<br>
<br>
As proposed by Francis, this is when you need to "generate" a corresponding<br>
tracepoint definition and call the tracepoint() call with the appropriate<br>
arguments.<br>
<br>
As Francis demonstrated we do not see any reason for lttng-ust not to work here<br>
given that you compile the libshim object correctly.<br>
<br>
> 5. `log(...)` is a thin interface to spdlog<br>
> <<a href="https://github.com/gabime/spdlog" rel="noreferrer" target="_blank">https://github.com/gabime/spdlog</a>> that handles `__attribute__`-based<br>
> setup and teardown of a logger.<br>
> <br>
> So at the end of the day, the shim developer provides:<br>
> <br>
> - The whitelist of mangled names<br>
> - Implementations of struct "wrappers" that provide custom ostream<br>
> operators<br>
> - A map between type names and wrapper names<br>
> <br>
> The machinery here seems fairly general-purpose, but I don't presume to be<br>
> an expert. My implementation is somewhat error-prone, and my main hope in<br>
> reaching out to the mailing list was that LTTng already had some of these<br>
> steps better-implemented.<br>
<br>
AFAIK, lttng does not have an equivalent.<br>
<br>
> Step #2 is particularly problematic due to<br>
> ambiguities in the mangling grammar, and will need support going forward to<br>
> generalize well.<br>
<br>
What is the status of this step in your project?<br>
<br>
What are the problems that make your implementation "error-pone"?<br>
<br>
Would you mind linking us to said project so we can have a look?<br>
<br>
I would be interested in seeing at first lttng tracepoint used as Francis<br>
demonstrated and see from there were this project can go.<br>
<br>
> <br>
> I would be happy to contribute some or all of my implementation if it's<br>
> something that the LTTng community would be interested in supporting and<br>
> extending.<br>
<br>
We are clearly open for discussion and helping you improve the project. I am not<br>
so sure on supporting and extending it. Others might have a different opinion.<br>
<br>
<br>
Cheers<br>
<br>
--<br>
Jonathan Rajotte-Julien<br>
EfficiOS<br>
</blockquote></div></div></div>