Skip to contentSkip to conversation

LTTng-UST alternative to LD_PRELOAD

DISCUSSION Woegerer, Paul 2 participants 2 messages Jul 19, 2012 – Jul 20, 2012 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 1339945703.2599.21.camel@DellE5500

Woegerer, Paul

author
#1 lore raw
Quoted 18 lines · 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;

Quoted 8 lines
   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

Signature · 7 lines
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.
#2 lore raw
In reply to a message not in the archive
Quoted 11 lines · * Lars ([email protected]) 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.

Quoted 9 lines

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

?

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

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

Quoted 13 lines

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

Best Regards,
Lars Ekman

_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Signature · 4 lines
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com