<div dir="ltr"><div>Ok, after further review and some performance analysis on spdlog, I'm considering skipping the tracef(...) step and jumping to a tracepoint-based approach. I believe I can use code generation to create both (1) the tracepoint definitions and (2) function interposition (LD_PRELOAD) shims calling to #1. This may take some time, but I'll ping this thread if I encounter any issues. Thanks! ~br<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 25, 2019 at 9:35 AM Philippe Proulx <<a href="mailto:eeppeliteloop@gmail.com">eeppeliteloop@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jan 25, 2019 at 4:05 AM Brian Rossa <<a href="mailto:br@f0cal.com" target="_blank">br@f0cal.com</a>> wrote:<br>
><br>
> Francis,<br>
><br>
> These are great suggestions, thanks!<br>
><br>
>> #Third idea:<br>
>> Do you know of tracef() [3] ? Using it, you can save any string to a<br>
>> UST trace. As a first step, you could directly replace your calls to<br>
>> spdlog by calls to tracef. It's an highly inefficient way of using<br>
>> LTTng, but it works (and probably lower overhead than writing to a<br>
>> file).<br>
><br>
><br>
> Replacing spdlog::debug(...) with tracef(...) may be an easy way for me to get familiar with LTTNg workflows without having to go through a complete port.<br>
<br>
However please note that spdlog uses {fmt} while tracef() uses a<br>
vsnprintf()-family function, so you would need to adapt the format<br>
strings too.<br>
<br>
Phil<br>
<br>
><br>
> This brings up an interesting question, though, and the answer may motivate me to close the gap further: What kind of latency reduction can I expect from moving from spdlog to LLTng? I know this is ill-posed without knowing more about how many pseudo-tracepoints I'm implementing, the log message sizes that I'm pushing to disk, etc, etc., but something notional would help my motivation.<br>
><br>
>><br>
>> You mentioned that you wrap structures with ostreams to output them in<br>
>> text format. Can you explain this a bit more?<br>
><br>
><br>
> I'm just implementing what spdlog suggests: <a href="https://github.com/gabime/spdlog#user-defined-types" rel="noreferrer" target="_blank">https://github.com/gabime/spdlog#user-defined-types</a><br>
><br>
> Cheers!<br>
> ~br<br>
><br>
> On Thu, Jan 24, 2019 at 11:06 AM Francis Deslauriers <<a href="mailto:francis.deslauriers@efficios.com" target="_blank">francis.deslauriers@efficios.com</a>> wrote:<br>
>><br>
>> "<br>
>><br>
>> Le mer. 23 janv. 2019, à 19 h 20, Brian Rossa <<a href="mailto:br@f0cal.com" target="_blank">br@f0cal.com</a>> a écrit :<br>
>> ><br>
>> > Jonathan,<br>
>> ><br>
>> > Responses below:<br>
>> ><br>
>> >> AFAIK, lttng does not have an equivalent.<br>
>> ><br>
>> ><br>
>> > 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>
>> ><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>
>> ><br>
>> > 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>
>><br>
>> Hi Brian,<br>
>><br>
>> If you have a list of the argument types, you can programmatically<br>
>> generate the tracepoint descriptions and callsites accordingly. The<br>
>> main blocker I see here is tracing arguments that are pointers to<br>
>> classes or containers. We need to be able to map each argument with a<br>
>> CTF type [1]. It's easy enough for int, float and char * but it's<br>
>> harder for complex structs and data structures.<br>
>><br>
>> You mentioned that you wrap structures with ostreams to output them in<br>
>> text format. Can you explain this a bit more?<br>
>><br>
>> Here are a few ideas:<br>
>><br>
>> #First idea<br>
>> If you are already defining the printing format and order of each of<br>
>> the fields of each structures in your libfoo.so maybe you could do the<br>
>> same but in LTTng-UST format. See "my-custom-structure.h" example [2].<br>
>><br>
>> #Second idea:<br>
>> If you prefer not convert those ostreams wrappers to ctf wrapper, you<br>
>> could reuse them to generate CTF_STRINGs.<br>
>> 1. Simple data types (int, float, char*) are mapped directly to CTF types,<br>
>> 2. Complex data types are wrapped with ostream function,<br>
>> 3. Complex data types are saved in the trace as CTF_STRING using the ostream.<br>
>> All this could be done by the boilerplate scripts I mentioned earlier.<br>
>> By using string format for some argument, you don't get the full power<br>
>> of LTTng but it will still be faster that saving everything in text.<br>
>><br>
>> #Third idea:<br>
>> Do you know of tracef() [3] ? Using it, you can save any string to a<br>
>> UST trace. As a first step, you could directly replace your calls to<br>
>> spdlog by calls to tracef. It's an highly inefficient way of using<br>
>> LTTng, but it works (and probably lower overhead than writing to a<br>
>> file).<br>
>><br>
>> [1]: <a href="https://lttng.org/man/3/lttng-ust/v2.10/" rel="noreferrer" target="_blank">https://lttng.org/man/3/lttng-ust/v2.10/</a><br>
>> [2]: <a href="https://lttng.org/docs/v2.10/#doc-defining-tracepoints" rel="noreferrer" target="_blank">https://lttng.org/docs/v2.10/#doc-defining-tracepoints</a><br>
>> [3]: <a href="https://lttng.org/docs/v2.10/#doc-tracef" rel="noreferrer" target="_blank">https://lttng.org/docs/v2.10/#doc-tracef</a><br>
>><br>
>> Thank you,<br>
>> Francis<br>
>><br>
>> ><br>
>> >><br>
>> >> What are the problems that make your implementation "error-pone"?<br>
>> ><br>
>> ><br>
>> > Use of regex as above.<br>
>> ><br>
>> >><br>
>> >> Would you mind linking us to said project so we can have a look?<br>
>> ><br>
>> ><br>
>> > 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.<br>
>> ><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>
>> >><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>
>> > Sounds good. Looking forward to connecting via personal email.<br>
>> ><br>
>> > Cheers!<br>
>> > ~br<br>
>> ><br>
>> ><br>
>> > On Tue, Jan 22, 2019 at 2:17 PM Jonathan Rajotte-Julien <<a href="mailto:jonathan.rajotte-julien@efficios.com" target="_blank">jonathan.rajotte-julien@efficios.com</a>> wrote:<br>
>> >><br>
>> >> 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>
>><br>
>><br>
>><br>
>> --<br>
>> Francis Deslauriers<br>
>> Computer Engineer<br>
>> EfficiOS inc.<br>
><br>
> _______________________________________________<br>
> lttng-dev mailing list<br>
> <a href="mailto:lttng-dev@lists.lttng.org" target="_blank">lttng-dev@lists.lttng.org</a><br>
> <a href="https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" rel="noreferrer" target="_blank">https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
</blockquote></div>