| LTRACE(1) | User Commands | LTRACE(1) |
ltrace - A library call tracer
ltrace [-e filter|-L] [-l|--library=library_pattern] [-x filter] [-S] [-b|--no-signals] [-i] [-w|--where=nr] [-r|-t|-tt|-ttt] [-T] [[-F|--config] pathlist] [-A maxelts] [-s strsize] [-C|--demangle] [-a|--align column] [-n|--indent nr] [-o|--output filename] [-D|--debug mask] [-u username] [-f] [-p pid] [[--] command [arg ...]]
ltrace -c [-e filter|-L] [-l|--library=library_pattern] [-x filter] [-S] [-o|--output filename] [-f] [-p pid] [[--] command [arg ...]]
ltrace -V|--version
ltrace -h|--help
ltrace is a program that simply runs the specified command until it exits. It intercepts and records the dynamic library calls which are called by the executed process and the signals which are received by that process. It can also intercept and print the system calls executed by the program.
Its use is very similar to strace(1).
ltrace shows parameters of invoked functions and system calls. To determine what arguments each function has, it needs external declaration of function prototypes. Those are stored in files called prototype libraries--see ltrace.conf(5) for details on the syntax of these files. See the section PROTOTYPE LIBRARY DISCOVERY to learn how ltrace finds prototype libraries.
Note that while this option selects calls that might be directed to the selected libraries, there's no actual guarantee that the call won't be directed elsewhere due to e.g. LD_PRELOAD or simply dependency ordering. If you want to make sure that symbols in given library are actually called, use -x @library_pattern instead.
Filters are specified with the -l, -e and -x options. In short they mean:
Suppose I have a library defined with this header tstlib.h:
void func_f_lib(void); void func_g_lib(void);
and this implementation tstlib.c:
#include "tstlib.h"
void func_f_lib(void)
{
func_g_lib();
}
void func_g_lib(void)
{
}
Suppose I have an executable that uses this library defined like this tst.c:
#include "tstlib.h"
void func_f_main(void)
{
}
void main(void)
{
func_f_main();
func_f_lib();
}
If linking without -Bsymbolic, the internal func_g_lib() call uses the PLT like external calls, and thus ltrace says:
$ ltrace -x 'func*' -L ./tst func_f_main() = <void> func_f_lib@tstlib.so( <unfinished ...> func_g_lib@tstlib.so() = <void> <... func_f_lib resumed> ) = <void> +++ exited (status 163) +++
$ ltrace -e 'func*' ./tst tst->func_f_lib( <unfinished ...> tstlib.so->func_g_lib() = <void> <... func_f_lib resumed> ) = <void> +++ exited (status 163) +++
$ ltrace -l tstlib.so ./tst tst->func_f_lib( <unfinished ...> tstlib.so->func_g_lib() = <void> <... func_f_lib resumed> ) = <void> +++ exited (status 163) +++
By contrast, if linking with -Bsymbolic, then the internal func_g_lib() call bypasses the PLT, and ltrace says:
$ ltrace -x 'func*' -L ./tst func_f_main() = <void> func_f_lib@tstlib.so( <unfinished ...> func_g_lib@tstlib.so() = <void> <... func_f_lib resumed> ) = <void> +++ exited (status 163) +++
$ ltrace -e 'func*' ./tst tst->func_f_lib() = <void> +++ exited (status 163) +++
$ ltrace -l tstlib.so ./tst tst->func_f_lib() = <void> +++ exited (status 163) +++
Filter expression is a chain of glob- or regexp-based rules that are used to pick symbols for tracing from libraries that the process uses. Most of it is intuitive, so as an example, the following would trace calls to malloc and free, except those done by libc:
-e malloc+free-@libc.so*
This reads: trace malloc and free, but don't trace anything that comes from libc. Semi-formally, the syntax of the above example looks approximately like this:
{[+-][symbol_pattern][@library_pattern]}
Symbol_pattern is used to match symbol names, library_pattern to match library SONAMEs. Both are implicitly globs, but can be regular expressions as well (see below). The glob syntax supports meta-characters * and ? and character classes, similarly to what basic bash globs support. ^ and $ are recognized to mean, respectively, start and end of given name.
Both symbol_pattern and library_pattern have to match the whole name. If you want to match only part of the name, surround it with one or two *'s as appropriate. The exception is if the pattern is not mentioned at all, in which case it's as if the corresponding pattern were *. (So malloc is really malloc@* and @libc.* is really *@libc.*.)
In libraries that don't have an explicit SONAME, basename is taken for SONAME. That holds for main binary as well: /bin/echo has an implicit SONAME of echo. In addition to that, special library pattern MAIN always matches symbols in the main binary and never a library with actual SONAME MAIN (use e.g. ^MAIN or [M]AIN for that).
If the symbol or library pattern is surrounded in slashes (/like this/), then it is considered a regular expression instead. As a shorthand, instead of writing /x/@/y/, you can write /x@y/.
If the library pattern starts with a slash, it is not a SONAME expression, but a path expression, and is matched against the library path name.
The first rule may lack a sign, in which case + is assumed. If, on the other hand, the first rule has a - sign, it is as if there was another rule @ in front of it, which has the effect of tracing complement of given rule.
The above rules are used to construct the set of traced symbols. Each candidate symbol is passed through the chain of above rules. Initially, the symbol is unmarked. If it matches a + rule, it becomes marked, if it matches a - rule, it becomes unmarked again. If, after applying all rules, the symbol is marked, it will be traced.
When a library is mapped into the address space of a traced process, ltrace needs to know what the prototypes are of functions that this library implements. For purposes of ltrace, prototype really is a bit more than just type signature: it's also formatting of individual parameters and of return value. These prototypes are stored in files called prototype libraries.
After a library is mapped, ltrace finds out what its SONAME is. It then looks for a file named SONAME.conf--e.g. protolib for libc.so.6 would be in a file called libc.so.6.conf. When such file is found (more about where ltrace looks for these files is below), ltrace reads all prototypes stored therein. When a symbol table entry point (such as those traced by -x) is hit, the prototype is looked up in a prototype library corresponding to the library where the hit occurred. When a library call (such as those traced by -e and -l) is hit, the prototype is looked up in all prototype libraries loaded for given process. That is necessary, because a library call is traced in a PLT table of a caller library, but the prototype is described at callee library.
If a library has no SONAME, basename of library file is considered instead. For the main program binary, basename is considered as well (e.g. protolib for /bin/echo would be called echo.conf). If a name corresponding to soname (e.g. libc.so.6.conf) is not found, and the module under consideration is a shared library, ltrace also tries partial matches. Ltrace snips one period after another, retrying the search, until either a protolib is found, or X.so is all that's left. Thus libc.so.conf would be considered, but libc.conf not.
When looking for a prototype library, ltrace potentially looks into several directories. On Linux, those are $XDG_CONFIG_HOME/ltrace, $HOME/.ltrace, X/ltrace for each X in $XDG_CONFIG_DIRS and /usr/share/ltrace. If the environment variable XDG_CONFIG_HOME is not defined, ltrace looks into $HOME/.config/ltrace instead.
There's also a mechanism for loading legacy config files. If $HOME/.ltrace.conf exists it is imported to every loaded prototype library. Similarly for /etc/ltrace.conf. If both exist, both are imported, and $HOME/.ltrace.conf is consulted before /etc/ltrace.conf.
If -F contains any directories, those are searched in precedence to the above system directories, in the same order in which they are mentioned in -F. Any files passed in -F are imported similarly to above legacy config files, before them.
See ltrace.conf(5) for details on the syntax of ltrace prototype library files.
It has most of the bugs stated in strace(1).
It only works on Linux and in some architectures.
If you would like to report a bug, send a message to the mailing list (ltrace-devel@lists.alioth.debian.org), or use the reportbug(1) program if you are under the Debian GNU/Linux distribution.
Juan Cespedes <cespedes@debian.org>
Petr Machata <pmachata@redhat.com>
ltrace.conf(5), strace(1), ptrace(2)
| January 2013 |