[lttng-dev] [RFC PATCH lttng-ust] Implement register_done waiting via LD_AUDIT

Woegerer, Paul Paul_Woegerer at mentor.com
Wed Jul 2 03:42:49 EDT 2014

On 07/01/2014 07:14 PM, Alexander Monakov wrote:
> On Tue, 1 Jul 2014, Woegerer, Paul wrote:
>> Unfortunately the current approach of delaying execution of main until
>> lttng-ust is available has several drawbacks. E.g. the dynamic linker
>> lock is taken during the execution the static ctor. Using glibc
>> functions that also require the same lock as part of the lttng-ust
>> initialization easily gets us into a deadlock situation.
> That's surprising; in my experience dlopen/dlsym from a static DSO ctor work,
> so I wonder what functions are causing a deadlock for you.

Base address state tracing, see liblttng-ust/lttng-ust-baddr.c:189

       dl_iterate_phdr(extract_soinfo_events, &data);

>> This patch is trying to delay execution of main with a different
>> technique (using a named semaphore in la_preinit to wait for lttng-ust
>> initialization).
> Frankly I don't think LD_AUDIT is the right tool for the job in this case,
> even ignoring its flakiness in glibc; better to fix your current approach if
> possible.

This is just an RFC. I'm not saying it should be merged as it is. I just
want to discuss the situation so that we find a better solution.

The current approach is to delay the execution of the application by
putting a sem_wait into the static ctor of lttng-ust (lttng_ust_init).

If you gave a better idea how to make the application wait on the
initialization of lttng-ust (handle_register_done) that does not prevent
the static ctor from completing please share it with me.

>> Having a stable LD_AUDIT interface would be extremely valuable in the
>> context of tracing.
> Oh, but the interface is extremely stable, it was unchanging for a long time
> now; it's just the implementation... ;)  (sorry, could not resist)

Being cynic won't help us either. I just saw your comments on
It's a shame that your patch is not in mainline.

> Also note that LD_AUDIT on Linux is glibc-specific, not available on other
> libcs that are otherwise quite useful, such as Bionic.

That's a problem. I agree.

Thanks for your comments,

Paul Woegerer, SW Development Engineer
Sourcery Analyzer <http://go.mentor.com/sourceryanalyzer>
Mentor Graphics, Embedded Software Division

More information about the lttng-dev mailing list