LTTng-UST alternative to LD_PRELOAD

LTTng-UST alternative to LD_PRELOAD

[Lars]

Hello,

I have recently started to use LTTng-UST and am using LD_PRELOAD
to make it possilbe to execute instrumented code on systems without
LTTng-UST installed.

To define LD_PRELOAD however affects too much. For instance all
forked processes also get the library loaded. This can be fixed by
removing the library from the LD_PRELOAD variable early in the main
function. This looks odd and required some explaining in comments.

Also, in my case, the instrumented program is started with a "wrapper"
program which I can not alter. This wrapper also gets the library
loaded.

As an alternative to using LD_PRELOAD I would like to use an explicit
function, like;

  int traceload(char const* library_path);

that is called early in main (instead of the LD_PRELOAD environment
manipulation) and loads the library with dlopen if it exists.

I have already tried this (of course) and it almost works already.
The tracepoints becomes visible but I get no trace data written.
So I think a really small modification is needed.

Is anything like this planned?

Or can anybody give me a hint on what is missing?

I checked the mailing list a couple of months back but did not
find anything.

Best Regards,
Lars Ekman

Re: LTTng-UST alternative to LD_PRELOAD

[Mathieu Desnoyers]

* Lars (lars@grandepotatis.se) wrote:
> 
> Hello,
> 
> I have recently started to use LTTng-UST and am using LD_PRELOAD
> to make it possilbe to execute instrumented code on systems without
> LTTng-UST installed.
> 
> To define LD_PRELOAD however affects too much. For instance all
> forked processes also get the library loaded. This can be fixed by
> removing the library from the LD_PRELOAD variable early in the main
> function. This looks odd and required some explaining in comments.

good point. LD_PRELOAD was originally the only way we allowed lttng-ust
to be loaded, because during the rc phase of the lttng-ust 2.0
development, we had issues with dlopening liblttng-ust. This has been
fixed within the rc stages though, so we could go for a dlopen approach
now.

> 
> Also, in my case, the instrumented program is started with a "wrapper"
> program which I can not alter. This wrapper also gets the library
> loaded.
> 
> As an alternative to using LD_PRELOAD I would like to use an explicit
> function, like;
> 
>   int traceload(char const* library_path);

or maybe:

int lttng_ust_dlopen(const char *library_path);

?

> that is called early in main (instead of the LD_PRELOAD environment
> manipulation) and loads the library with dlopen if it exists.

yep, makes sense.

> 
> I have already tried this (of course) and it almost works already.
> The tracepoints becomes visible but I get no trace data written.
> So I think a really small modification is needed.
> 
> Is anything like this planned?

if you can provide a patch, I'd be glad to review & merge it.

> 
> Or can anybody give me a hint on what is missing?

Try running your app with the env. var LTTNG_UST_DEBUG=1  set. It might
provide helpful info. If you still have problems, please post your patch
as RFC along with specific test programs so we can look at the behavior.

Thanks,

Mathieu

> 
> I checked the mailing list a couple of months back but did not
> find anything.
> 
> Best Regards,
> Lars Ekman
> 
> 
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

Re: LTTng-UST alternative to LD_PRELOAD

[Woegerer, Paul]

On 06/17/2012 05:08 PM, Lars wrote:
> Hello,
>
> I have recently started to use LTTng-UST and am using LD_PRELOAD
> to make it possilbe to execute instrumented code on systems without
> LTTng-UST installed.
>
> To define LD_PRELOAD however affects too much. For instance all
> forked processes also get the library loaded. This can be fixed by
> removing the library from the LD_PRELOAD variable early in the main
> function. This looks odd and required some explaining in comments.
>
> Also, in my case, the instrumented program is started with a "wrapper"
> program which I can not alter. This wrapper also gets the library
> loaded.
>
> As an alternative to using LD_PRELOAD I would like to use an explicit
> function, like;
>
>    int traceload(char const* library_path);
>
> that is called early in main (instead of the LD_PRELOAD environment
> manipulation) and loads the library with dlopen if it exists.
>
> I have already tried this (of course) and it almost works already.
> The tracepoints becomes visible but I get no trace data written.
> So I think a really small modification is needed.

Another alternative would be to implement an lttng-backend for latrace ( 
see: http://people.redhat.com/jolsa/latrace/index.shtml ).

Library calls from the following headers are supported as of version 
0.5.11:

ctype.h   dlfcn.h  getopt.h  ioctl.h    libintl.h  locale.h  mman.h netdb.h   pwd.h    signal.h  stat.h     stdlib.h   sysdeps   term.h time.h    unistd.h wait.h    dirent.h   fcntl.h    inet.h    latrace.h libio.h   misc.h   ncurses.h pthread.h  resource.h socket.h  stdio.h string.h  syslog.h termios.h typedefs.h utmp.h

So if we let latrace optionally emit lttng events for call enter and exit we would instantly get support for tracing for _any_ library call.

--
Paul

-- 
Paul Woegerer | SW Development Engineer
Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria
P 43.1.535991320
Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS

Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.