Header Ads Widget

[MAN] ltrace

Content-type: text/html; charset=UTF-8 Man page of LTRACE

LTRACE

Section: User Commands (1)
Updated: January 2013
Index Return to Main Contents
 

NAME

ltrace - A library call tracer

 

SYNOPSIS

ltrace [-e filter|-L] [-l|--library=library_pattern] [-x filter] [-S] [-b|--no-signals] [-i] [-w|--where=nr] [-r|-t|-tt|-ttt] [-T] [-F filename] [-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

 

DESCRIPTION

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

 

OPTIONS

-a, --align column
Align return values in a specific column (default column is 5/8 of screen width).
-A maxelts
Maximum number of array elements to print before suppressing the rest with an ellipsis ("..."). This also limits number of recursive structure expansions.
-b, --no-signals
Disable printing of signals recieved by the traced process.
-c
Count time and calls for each library call and report a summary on program exit.
-C, --demangle
Decode (demangle) low-level symbol names into user-level names. Besides removing any initial underscore prefix used by the system, this makes C++ function names readable.
-D, --debug mask
Show debugging output of ltrace itself. mask is a number with internal meaning that's not really well defined at all. mask of 77 shows all debug messages, which is what you usually need.
-e filter
A qualifying expression which modifies which library calls to trace. The format of the filter expression is described in the section FILTER EXPRESSIONS. If more than one -e option appears on the command line, the library calls that match any of them are traced. If no -e is given, @MAIN is assumed as a default.
-f
Trace child processes as they are created by currently traced processes as a result of the fork(2) or clone(2) system calls. The new process is attached immediately.
-F filename
Load an alternate config file. Normally, /etc/ltrace.conf and ~/.ltrace.conf will be read (the latter only if it exists). Use this option to load the given file or files instead of those two default files. See ltrace.conf(5) for details on the syntax of ltrace configuration files.
-h, --help
Show a summary of the options to ltrace and exit.
-i
Print the instruction pointer at the time of the library call.
-l, --library library_pattern
Display only calls to functions implemented by libraries that match library_pattern. Multiple library patters can be specified with several instances of this option. Syntax of library_pattern is described in section FILTER EXPRESSIONS.

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.

-L
When no -e option is given, don't assume the default action of @MAIN.
-n, --indent nr
Indent trace output by nr spaces for each level of call nesting. Using this option makes the program flow visualization easy to follow. This indents uselessly also functions that never return, such as service functions for throwing exceptions in the C++ runtime.
-o, --output filename
Write the trace output to the file filename rather than to stderr.
-p pid
Attach to the process with the process ID pid and begin tracing. This option can be used together with passing a command to execute. It is possible to attach to several processes by passing more than one option -p.
-r
Print a relative timestamp with each line of the trace. This records the time difference between the beginning of successive lines.
-s strsize
Specify the maximum string size to print (the default is 32).
-S
Display system calls as well as library calls
-t
Prefix each line of the trace with the time of day.
-tt
If given twice, the time printed will include the microseconds.
-ttt
If given thrice, the time printed will include the microseconds and the leading portion will be printed as the number of seconds since the epoch.
-T
Show the time spent inside each call. This records the time difference between the beginning and the end of each call.
-u username
Run command with the userid, groupid and supplementary groups of username. This option is only useful when running as root and enables the correct execution of setuid and/or setgid binaries.
-w, --where nr
Show backtrace of nr stack frames for each traced function. This option enabled only if libunwind support was enabled at compile time.
-x filter
A qualifying expression which modifies which symbol table entry points to trace. The format of the filter expression is described in the section FILTER EXPRESSIONS. If more than one -x option appears on the command line, the symbols that match any of them are traced. No entry points are traced if no -x is given.
-V, --version
Show the version number of ltrace and exit.

 

FILTER EXPRESSIONS

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.

 

BUGS

It has most of the bugs stated in strace(1).

It only works on Linux and in a small subset of 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.

 

FILES

/etc/ltrace.conf
System configuration file
~/.ltrace.conf
Personal config file, overrides /etc/ltrace.conf

 

AUTHOR

Juan Cespedes <cespedes@debian.org>
Petr Machata <pmachata@redhat.com>

 

SEE ALSO

ltrace.conf(5), strace(1), ptrace(2)


 

Index

NAME
SYNOPSIS
DESCRIPTION
OPTIONS
FILTER EXPRESSIONS
BUGS
FILES
AUTHOR
SEE ALSO

This document was created by man2html, using the manual pages.
Time: 04:45:23 GMT, September 16, 2022 Content-type: text/html; charset=UTF-8 Man page of ltrace.conf

ltrace.conf

Section: ltrace configuration file (5)
Updated: October 2012
Index Return to Main Contents
 

NAME

ltrace.conf - Configuration file for ltrace(1).

 

DESCRIPTION

This manual page describes ltrace.conf, a file that describes prototypes of functions in binaries for ltrace(1) to use. Ltrace needs this information to display function call arguments.

Each line of a configuration file describes at most a single item. Lines composed entirely of white space are ignored, as are lines starting with semicolon character (comment lines). Described items can be either function prototypes, or definitions of type aliases.

 

PROTOTYPES

A prototype describes return type and parameter types of a single function. The syntax is as follows:

LENS NAME ([LENS{,LENS}]);

NAME is the (mangled) name of a symbol. In the elementary case, LENS is simply a type. Both lenses and types are described below. For example, a simple function prototype might look like this:

int kill(int,int);

Despite the apparent similarity with C, ltrace.conf is really its own language that's only somewhat inspired by C.

 

TYPES

Ltrace understands a range of primitive types. Those are interpreted according to C convention native on a given architecture. E.g. ulong is interpreted as 4-byte unsigned integer on 32-bit GNU/Linux machine, but 8-byte unsigned integer on 64-bit GNU/Linux machine.

void
Denotes that a function does not return anything. Can be also used to construct a generic pointer, i.e. pointer-sized number formatted in hexadecimal format.
char
8-bit quantity rendered as a character
ushort,short
Denotes unsigned or signed short integer.
uint,int
Denotes unsigned or signed integer.
ulong,long
Denotes unsigned or signed long integer.
float
Denotes floating point number with single precision.
double
Denotes floating point number with double precision.

Besides primitive types, the following composed types are possible:

struct([LENS{,LENS}])
Describes a structure with given types as fields, e.g. struct(int,int,float).

Alignment is computed as customary on the architecture. Custom alignment (e.g. packed structs) and bit-fields are not supported. It's also not possible to differentiate between structs and non-POD C++ classes, for arches where it makes a difference.

array(LENS,EXPR)
Describes array of length EXPR, which is composed of types described by LENS, e.g. array(int, 6).

Note that in C, arrays in role of function argument decay into pointers. Ltrace currently handles this automatically, but for full formal correctness, any such arguments should be described as pointers to arrays.

LENS*
Describes a pointer to a given type, e.g. char* or int***. Note that the former example actually describes a pointer to a character, not a string. See below for string lens, which is applicable to these cases.

 

LENSES

Lenses change the way that types are described. In the simplest case, a lens is directly a type. Otherwise a type is decorated by the lens. Ltrace understands the following lenses:

oct(TYPE)
The argument, which should be an integer type, is formatted in base-8.

hex(TYPE)
The argument, which should be an integer or floating point type, is formatted in base-16. Floating point arguments are converted to double and then displayed using the %a fprintf modifier.

hide(TYPE)
The argument is not shown in argument list.

bool(TYPE)
Arguments with zero value are shown as "false", others are shown as "true".

bitvec(TYPE)
Underlying argument is interpreted as a bit vector and a summary of bits set in the vector is displayed. For example if bits 3,4,5 and 7 of the bit vector are set, ltrace shows <3-5,7>. Empty bit vector is displayed as <>. If there are more bits set than unset, inverse is shown instead: e.g. ~<0> when a number 0xfffffffe is displayed. Full set is thus displayed ~<>.

If the underlying type is integral, then bits are shown in their natural big-endian order, with LSB being bit 0. E.g. bitvec(ushort) with value 0x0102 would be displayed as <1,8>, irrespective of underlying byte order.

For other data types (notably structures and arrays), the underlying data is interpreted byte after byte. Bit 0 of first byte has number 0, bit 0 of second byte number 8, and so on. Thus bitvec(struct(int)) is endian sensitive, and will show bytes comprising the integer in their memory order. Pointers are first dereferenced, thus bitvec(array(char, 32)*) is actually a pointer to 256-bit bit vector.

string(TYPE)
string[EXPR]
string

The first form of the argument is canonical, the latter two are syntactic sugar. In the canonical form, the function argument is formatted as string. The TYPE shall be either a char*, or array(char,EXPR), or array(char,EXPR)*. If an array is given, the length will typically be a zero expression (but doesn't have to be). Using argument that is plain array (i.e. not a pointer to array) makes sense e.g. in C structs, in cases like struct(string(array(char, 6))), which describes the C type struct {char s[6];}.

Because simple C-like strings are pretty common, there are two shorthand forms. The first shorthand form (with brackets) means the same as string(array(char, EXPR)*). Plain string without an argument is then taken to mean the same as string[zero].

Note that char* by itself describes a pointer to a char. Ltrace will dereference the pointer, and read and display the single character that it points to.

enum(NAME[=VALUE]{,NAME[=VALUE]})
enum[TYPE](NAME[=VALUE]{,NAME[=VALUE]})

This describes an enumeration lens. If an argument has any of the given values, it is instead shown as the corresponding NAME. If a VALUE is omitted, the next consecutive value following after the previous VALUE is taken instead. If the first VALUE is omitted, it's 0 by default.

TYPE, if given, is the underlying type. It is thus possible to create enums over shorts or longs---arguments that are themselves plain, non-enum types in C, but whose values can be meaningfully described as enumerations. If omitted, TYPE is taken to be int.

 

TYPE ALIASES

A line in config file can, instead of describing a prototype, create a type alias. Instead of writing the same enum or struct on many places (and possibly updating when it changes), one can introduce a name for such type, and later just use that name:

typedef NAME = LENS;

 

RECURSIVE STRUCTURES

Ltrace allows you to express recursive structures. Such structures are expanded to the depth described by the parameter -A. To declare a recursive type, you first have to introduce the type to ltrace by using forward declaration. Then you can use the type in other type definitions in the usual way:

typedef NAME = struct;
typedef NAME = struct(NAME can be used here)

For example, consider the following singy-linked structure and a function that takes such list as an argument:

typedef int_list = struct;
typedef int_list = struct(int, int_list*);
void ll(int_list*);

Such declarations might lead to an output like the following:

ll({ 9, { 8, { 7, { 6, ... } } } }) = <void>

Ltrace detects recursion and will not expand already-expanded structures. Thus a doubly-linked list would look like the following:

typedef int_list = struct;
typedef int_list = struct(int, int_list*, int_list*);

With output e.g. like:

ll({ 9, { 8, { 7, { 6, ..., ... }, recurse^ }, recurse^ }, nil })

The "recurse^" tokens mean that given pointer points to a structure that was expanded in the previous layer. Simple "recurse" would mean that it points back to this object. E.g. "recurse^^^" means it points to a structure three layers up. For doubly-linked list, the pointer to the previous element is of course the one that has been just expanded in the previous round, and therefore all of them are either recurse^, or nil. If the next and previous pointers are swapped, the output adjusts correspondingly:

ll({ 9, nil, { 8, recurse^, { 7, recurse^, { 6, ..., ... } } } })

 

EXPRESSIONS

Ltrace has support for some elementary expressions. Each expression can be either of the following:

NUM
An integer number.

argNUM
Value of NUM-th argument. The expression has the same value as the corresponding argument. arg1 refers to the first argument, arg0 to the return value of the given function.

retval
Return value of function, same as arg0.

eltNUM
Value of NUM-th element of the surrounding structure type. E.g. struct(ulong,array(int,elt1)) describes a structure whose first element is a length, and second element an array of ints of that length.

zero
zero(EXPR)

Describes array which extends until the first element, whose each byte is 0. If an expression is given, that is the maximum length of the array. If NUL terminator is not found earlier, that's where the array ends.

 

PARAMETER PACKS

Sometimes the actual function prototype varies slightly depending on the exact parameters given. For example, the number and types of printf parameters are not known in advance, but ltrace might be able to determine them in runtime. This feature has wider applicability, but currently the only parameter pack that ltrace supports is printf-style format string itself:

format
When format is seen in the parameter list, the underlying string argument is parsed, and GNU-style format specifiers are used to determine what the following actual arguments are. E.g. if the format string is "%s %d\n", it's as if the format was replaced by string, string, int.

 

RETURN ARGUMENTS

C functions often use one or more arguments for returning values back to the caller. The caller provides a pointer to storage, which the called function initializes. Ltrace has some support for this idiom.

When a traced binary hits a function call, ltrace first fetches all arguments. It then displays left portion of the argument list. Only when the function returns does ltrace display right portion as well. Typically, left portion takes up all the arguments, and right portion only contains return value. But ltrace allows you to configure where exactly to put the dividing line by means of a + operator placed in front of an argument:

int asprintf(+string*, format);

Here, the first argument to asprintf is denoted as return argument, which means that displaying the whole argument list is delayed until the function returns:

a.out->asprintf( <unfinished ...>
libc.so.6->malloc(100) = 0x245b010
[... more calls here ...]
<... asprintf resumed> "X=1", "X=%d", 1) = 5

It is currently not possible to have an "inout" argument that passes information in both directions.

 

EXAMPLES

In the following, the first is the C prototype, and following that is ltrace configuration line.

void func_charp_string(char str[]);
void func_charp_string(string);

enum e_foo {RED, GREEN, BLUE};
void func_enum(enum e_foo bar);

void func_enum(enum(RED,GREEN,BLUE));
- or -
typedef e_foo = enum(RED,GREEN,BLUE);
void func_enum(e_foo);

void func_arrayi(int arr[], int len);
void func_arrayi(array(int,arg2)*,int);

struct S1 {float f; char a; char b;};
struct S2 {char str[6]; float f;};
struct S1 func_struct(int a, struct S2, double d);

struct(float,char,char) func_struct_2(int, struct(string(array(char, 6)),float), double);

 

AUTHOR

Petr Machata <pmachata@redhat.com>


 

Index

NAME
DESCRIPTION
PROTOTYPES
TYPES
LENSES
TYPE ALIASES
RECURSIVE STRUCTURES
EXPRESSIONS
PARAMETER PACKS
RETURN ARGUMENTS
EXAMPLES
AUTHOR

This document was created by man2html, using the manual pages.
Time: 04:45:54 GMT, September 16, 2022

댓글 쓰기

0 댓글