[lttng-dev] [PATCH lttng-ust] Improve tracelog handling, reduce exported functions

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Thu May 20 11:21:38 EDT 2021

----- On May 20, 2021, at 10:57 AM, Norbert Lange nolange79 at gmail.com wrote:

> Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers
> <mathieu.desnoyers at efficios.com>:
>> ----- On May 20, 2021, at 8:18 AM, lttng-dev lttng-dev at lists.lttng.org wrote:
>> > Instead of creating functions for each loglevel, simply pass the
>> > callback as argument.
>> >
>> > Further pack all preprocessor information into a struct that
>> > the compiler already can prepare.
>> This introduces an ABI break too late in the cycle.
> So 2.14 would be the next chance I guess

No. The original ABI was introduced about 10 years ago with lttng-ust 2.0,
and lttng-ust 2.13 introduces the first ABI break since. I don't
plan on doing any ABI break in lttng-ust in the foreseeable future.

ABI breaks require that our users recompile all their instrumented
applications, which is really cumbersome for large software deployments.
We don't break ABI lightly.

We should rather introduce new features as extensions (new symbols).

>> Also, I'm not so keen on adding an indirect call on the fast-path
>> when it's not absolutely needed.
> Code seems pretty similar: https://godbolt.org/z/oK1WhWqGT

By fast-path, I also mean:

+        (*callback)(source->file, source->line, source->func, msg, len,
+                LTTNG_UST_CALLER_IP());

Which introduces an indirect call which needs to be taken when tracing
is active.

>> What is wrong with having one symbol per loglevel ?
> Macro-magic is cumbersome to edit, more code, more relocations.

If it was still time for ABI breaks, I would be tempted to consider it
especially given that tracelog and tracef are not expected to be "high-speed",
but now is too late for breaking ABI.

> Easier to adapt aswell, could roll my own tracelog functions while
> using lttng_ust__tracelog_printf (started soind that as I don't want
> to link to lttng-ust.so)

What prevents you from linking against lttng-ust.so again ?



Mathieu Desnoyers
EfficiOS Inc.

More information about the lttng-dev mailing list