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

[Woegerer, Paul]

Hi Alexander,

The idea of this patch is to prevent deadlocks in the initialization
phase of lttng-ust when forks (e.g. for daemons) are happening in the
traced application.

lttng-ust uses a semaphore to block further execution of the program
until lttng-ust is fully initialized (see lttng-ust-comm.c:1496 in
lttng_ust_init() "switch (timeout_mode)"). The initialization of
lttng-ust happens in the ust_listener_thread that gets started from
lttng_ust_init(). If initialization is done the semaphore gets posted
(search for sem_post) and the static ctor lttng_ust_init() is able to
complete.

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.

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).


Note that this is not the only issue that prevents us from using
LD_AUDIT effectively for our own purposes:

https://sourceware.org/bugzilla/show_bug.cgi?id=11177#c8
prevents us from using my current patch e.g. to trace firefox (and other
applications that link against libicu*.so)

https://sourceware.org/bugzilla/show_bug.cgi?id=16592 prevents us from
using LD_AUDIT as a generic function enter/exit framework for public
functions (all glibc functions, glib, ....).

Having a stable LD_AUDIT interface would be extremely valuable in the
context of tracing. Unfortunately in it's current state it's just a nice
toy to play with.


HTH,
Paul


On 07/01/2014 05:19 PM, Alexander Monakov wrote:
> Hello,
> 
> I'm not aware of the context of this patch, but please note that the amount of
> overhead from non-empty LD_AUDIT is currently extremely high in all released
> Glibc versions.  The forced high overhead is, as I understand, misaligned with
> LTTng's aim to provide low-overhead tracing.
> 
> Non-empty LD_AUDIT behaves as if one of auditing libraries provided PLT hooks.
> This causes the dynamic linker to install register save-restore helpers for
> each PLT call, even if they are not needed (if no PLT hooks were in fact
> provided).
> 
> Here's the Glibc bug that shows a ~19x slowdown on a microbenchmark that
> repeatedly calls sqrt() from libm.so.  The proposed patch was not accepted,
> with the review suggesting a different approach.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=15533
> 
> Could you explain the problem your patch aims to solve?  Sorry if it was
> already explained elsewhere; please point me to the discussion in that case.
> 
> Alexander
> 


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