[lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

[Mathieu Desnoyers]

On 2024-01-15 14:42, Florian Weimer wrote:
> * Mathieu Desnoyers:
> 
[...]
> 
> General use of lttng should be fine, I think, only the malloc wrapper
> has this problem.

The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS access
(or any unexpected memory access done as a side-effect from calling
libc) from within LTTng-UST instrumentation would internally attempt to
call recursively into the malloc wrapper. In that nested case, we skip
the instrumentation and call the libc function directly.

I agree with your conclusion that only this nesting counter gating variable
actually needs to be initial-exec.

> 
>> But moving all TLS variables used by lttng-ust from global-dynamic to
>> initial-exec is tricky, because a prior attempt to do so introduced
>> regressions in use-cases where lttng-ust was dlopen'd by Java or
>> Python, AFAIU situations where the runtimes were already using most of
>> the extra memory pool for dlopen'd libraries initial-exec variables,
>> causing dlopen of lttng-ust to fail.
> 
> Oh, right, that makes it quite difficult.  Could you link a private copy
> of the libraries into the wrapper that uses initial-exec TLS?

Unfortunately not easily, because by design LTTng-UST is meant to be a
singleton per-process. Changing this would have far-reaching impacts on
interactions with the LTTng-UST tracepoint instrumentation, as well as
impacts on synchronization between the LTTng-UST agent thread and
application calling fork/clone. Also AFAIR, the LTTng session daemon
(at least until recently) does not expect multiple concurrent
registrations from a given process.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com