[lttng-dev] UST tracing problem on ARM/Android

[Charles Briere]

So I just found out why this was hapenning and thought I would share my
findings.

The Android linker will load a shared library twice in memory if it has
a different path (even symbolic link). Therefore when
dl_opening("lttng-ust-tracepoint.so.0", ...), even if that library is
already loaded as it has been defined at link time, it will duplicate
all it's symbols. The function add_calliste will populate the
callsite_table which is local to the dl_open(ed) library while
tracepoint_sync_callsites will try to read an unitialized one, local to
it's own symbols. 

That brings me to ask, why not passing "liblttng-ust-tracepoint.so" to
dl_open()? What is the reason for versioning here as anyway at link
time, liblttng-ust-tracepoint.so is the one beeing used?

Thanks,
Charles

On Wed, 2015-01-14 at 14:17 -0800, Charles Briere wrote:
> Hello world,
> 
> I've been running in some inssues lately with UST on ARM/Android. Using
> the following to configure my session, I enable every ust event.
> 
> lttng create
> lttng enable-event -ua
> 
> Although, when a tracepoint is called, its state ( struct
> lttng_ust_tracepoint -> state) is 0. 
> 
> My understanding of the whole registration process is limited, so the
> following reasoning is probably flawed, so please correct me if that
> happens. 
> 
> I found out, that when registering the library
> (tracepoint_register_lib), callsite_table is populated. But later on
> when it comes to register the probes (lttng_prove_register),
> callsite_table 's address is different and the list is empty. As a
> result, when tracepoint_sync_callsite() is called, set_tracepoint() is
> never executed as looping through an empty list. 
> 
> What I don't understand in here, is that the callsite_table pointer is
> not the same during the lib registration and probe registration. Both
> are ran sequentially in the same thread and I can't figure what other
> operation could affect the variable. Any hint/help would be much
> appreciated.
> 
> Thanks,
> Charles