<div dir="ltr"><div>Francis,</div><div><br></div><div>These are great suggestions, thanks!</div><div><br><div><div class="gmail_quote"></div></div></div><div dir="ltr"><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">
#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></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div><div><div class="gmail_quote"><div>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.</div><div><br></div><div>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.</div><div> </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">
You mentioned that you wrap structures with ostreams to output them in<br>
text format. Can you explain this a bit more?<br>
</blockquote></div> </div><div>I'm just implementing what spdlog suggests: <a href="https://github.com/gabime/spdlog#user-defined-types">https://github.com/gabime/spdlog#user-defined-types</a><br></div></div></div></div></div><div dir="ltr"><div><br></div><div>Cheers!</div><div>~br<br></div><div><br><div class="gmail_quote"><div dir="ltr" class="m_2110191321372128786m_455641889000109838gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"<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>
</blockquote></div>
</div></div></div>