2 .\" Copyright (c) 2012, 2013 Petr Machata, Red Hat Inc.
3 .\" Copyright (c) 1997-2005 Juan Cespedes <cespedes@debian.org>
5 .\" This program is free software; you can redistribute it and/or
6 .\" modify it under the terms of the GNU General Public License as
7 .\" published by the Free Software Foundation; either version 2 of the
8 .\" License, or (at your option) any later version.
10 .\" This program is distributed in the hope that it will be useful, but
11 .\" WITHOUT ANY WARRANTY; without even the implied warranty of
12 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
13 .\" General Public License for more details.
15 .\" You should have received a copy of the GNU General Public License
16 .\" along with this program; if not, write to the Free Software
17 .\" Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
20 .TH ltrace.conf "5" "October 2012" "" "ltrace configuration file"
23 \fBltrace.conf\fR \- Configuration file for \fBltrace(1)\fR.
27 This manual page describes \fBltrace.conf\fR, a file that describes
28 prototypes of functions in binaries for \fBltrace(1)\fR to use.
29 Ltrace needs this information to display function call arguments.
31 Each line of a configuration file describes at most a single item.
32 Lines composed entirely of white space are ignored, as are lines
33 starting with semicolon or hash characters (comment lines). Described
34 items can be either function prototypes, or definitions of type
39 A prototype describes return type and parameter types of a single
40 function. The syntax is as follows:
43 \fILENS\fR \fINAME\fR \fB(\fR[\fILENS\fR{,\fILENS\fR}]\fB);\fR
46 \fINAME\fR is the (mangled) name of a symbol. In the elementary case,
47 \fILENS\fR is simply a type. Both lenses and types are described
48 below. For example, a simple function prototype might look like this:
51 .B int\fR kill\fB(int,int);
54 Despite the apparent similarity with C, \fBltrace.conf\fR is really
55 its own language that's only somewhat inspired by C.
59 Ltrace understands a range of primitive types. Those are interpreted
60 according to C convention native on a given architecture.
61 E.g. \fBulong\fR is interpreted as 4-byte unsigned integer on 32-bit
62 GNU/Linux machine, but 8-byte unsigned integer on 64-bit GNU/Linux
67 Denotes that a function does not return anything. Can be also used to
68 construct a generic pointer, i.e. pointer-sized number formatted in
72 8-bit quantity rendered as a character
75 Denotes unsigned or signed short integer.
78 Denotes unsigned or signed integer.
81 Denotes unsigned or signed long integer.
84 Denotes floating point number with single precision.
87 Denotes floating point number with double precision.
90 Besides primitive types, the following composed types are possible:
93 .B struct(\fR[\fILENS\fR{,\fILENS\fR}]\fB)\fR
94 Describes a structure with given types as fields,
95 e.g. \fBstruct(int,int,float)\fR.
97 Alignment is computed as customary on the architecture. Custom
98 alignment (e.g. packed structs) and bit-fields are not supported.
99 It's also not possible to differentiate between structs and non-POD
100 C++ classes, for arches where it makes a difference.
103 .B array(\fR\fILENS\fR\fB,\fIEXPR\fR\fB)
104 Describes array of length \fIEXPR\fR, which is composed of types
105 described by \fILENS\fR, e.g. \fBarray(int, \fR6\fB)\fR.
107 Note that in C, arrays in role of function argument decay into
108 pointers. Ltrace currently handles this automatically, but for full
109 formal correctness, any such arguments should be described as pointers
114 Describes a pointer to a given type, e.g. \fBchar*\fR or \fBint***\fR.
115 Note that the former example actually describes a pointer to a
116 character, not a string. See below for \fBstring\fR lens, which is
117 applicable to these cases.
121 Lenses change the way that types are described. In the simplest case,
122 a lens is directly a type. Otherwise a type is decorated by the lens.
123 Ltrace understands the following lenses:
127 The argument, which should be an integer type, is formatted in base-8.
131 The argument, which should be an integer or floating point type, is
132 formatted in base-16. Floating point arguments are converted to
133 double and then displayed using the \fB%a\fR fprintf modifier.
137 The argument is not shown in argument list.
141 Arguments with zero value are shown as "false", others are shown as
145 .B bitvec(\fITYPE\fB)
146 Underlying argument is interpreted as a bit vector and a summary of
147 bits set in the vector is displayed. For example if bits 3,4,5 and 7
148 of the bit vector are set, ltrace shows <3-5,7>. Empty bit vector is
149 displayed as <>. If there are more bits set than unset, inverse is
150 shown instead: e.g. ~<0> when a number 0xfffffffe is displayed. Full
151 set is thus displayed ~<>.
153 If the underlying type is integral, then bits are shown in their
154 natural big-endian order, with LSB being bit 0.
155 E.g. \fBbitvec(ushort)\fR with value 0x0102 would be displayed as
156 <1,8>, irrespective of underlying byte order.
158 For other data types (notably structures and arrays), the underlying
159 data is interpreted byte after byte. Bit 0 of first byte has number
160 0, bit 0 of second byte number 8, and so on. Thus
161 \fBbitvec(struct(int))\fR is endian sensitive, and will show bytes
162 comprising the integer in their memory order. Pointers are first
163 dereferenced, thus \fBbitvec(array(char, \fR32\fB)*)\fR is actually a
164 pointer to 256-bit bit vector.
167 .B string(\fITYPE\fB)
169 .B string[\fIEXPR\fB]
173 The first form of the argument is canonical, the latter two are
174 syntactic sugar. In the canonical form, the function argument is
175 formatted as string. The \fITYPE\fR can have either of the following
176 forms: \fIX\fB*\fR, or \fBarray(\fIX\fB,\fIEXPR\fB)\fR, or
177 \fBarray(\fIX\fB,\fIEXPR\fB)*\fR. \fIX\fR is either \fBchar\fR for
178 normal strings, or an integer type for wide-character strings.
180 If an array is given, the length will typically be a \fBzero\fR
181 expression (but doesn't have to be). Using argument that is plain
182 array (i.e. not a pointer to array) makes sense e.g. in C structs, in
183 cases like \fBstruct(string(array(char, \fR6\fB)))\fR, which describes
184 the C type \fBstruct {char \fRs\fB[\fR6\fB];}\fR.
186 Because simple C-like strings are pretty common, there are two
187 shorthand forms. The first shorthand form (with brackets) means the
188 same as \fBstring(array(char, \fIEXPR\fB)*)\fR. Plain \fBstring\fR
189 without an argument is then taken to mean the same as
192 Note that \fBchar*\fR by itself describes a pointer to a char. Ltrace
193 will dereference the pointer, and read and display the single
194 character that it points to.
197 .B enum(\fINAME\fR[\fB=\fIVALUE\fR]{,\fINAME\fR[\fB=\fIVALUE\fR]}\fB)
199 .B enum[\fITYPE\fB]\fB(\fINAME\fR[\fB=\fIVALUE\fR]{,\fINAME\fR[\fB=\fIVALUE\fR]}\fB)
201 This describes an enumeration lens. If an argument has any of the
202 given values, it is instead shown as the corresponding \fINAME\fR. If
203 a \fIVALUE\fR is omitted, the next consecutive value following after
204 the previous \fIVALUE\fR is taken instead. If the first \fIVALUE\fR
205 is omitted, it's \fB0\fR by default.
207 \fITYPE\fR, if given, is the underlying type. It is thus possible to
208 create enums over shorts or longs\(emarguments that are themselves
209 plain, non-enum types in C, but whose values can be meaningfully
210 described as enumerations. If omitted, \fITYPE\fR is taken to be
216 A line in config file can, instead of describing a prototype, create a
217 type alias. Instead of writing the same enum or struct on many places
218 (and possibly updating when it changes), one can introduce a name for
219 such type, and later just use that name:
222 \fBtypedef \fINAME\fB = \fILENS\fB;\fR
225 .SH RECURSIVE STRUCTURES
227 Ltrace allows you to express recursive structures. Such structures
228 are expanded to the depth described by the parameter \-A. To declare a
229 recursive type, you first have to introduce the type to ltrace by
230 using forward declaration. Then you can use the type in other type
231 definitions in the usual way:
234 .B typedef \fINAME\fB = struct;
236 .B typedef \fINAME\fB = struct(\fINAME\fR can be used here\fB)
239 For example, consider the following singy-linked structure and a
240 function that takes such list as an argument:
243 .B typedef\fR int_list \fB= struct;
245 .B typedef\fR int_list \fB= struct(int,\fR int_list\fB*);
247 .B void\fR ll\fB(\fRint_list\fB*);
250 Such declarations might lead to an output like the following:
253 ll({ 9, { 8, { 7, { 6, ... } } } }) = <void>
256 Ltrace detects recursion and will not expand already-expanded
257 structures. Thus a doubly-linked list would look like the following:
260 .B typedef\fR int_list \fB= struct;
262 .B typedef\fR int_list \fB= struct(int,\fR int_list\fB*,\fR int_list\fB*);
265 With output e.g. like:
268 ll({ 9, { 8, { 7, { 6, ..., ... }, recurse^ }, recurse^ }, nil })
271 The "recurse^" tokens mean that given pointer points to a structure
272 that was expanded in the previous layer. Simple "recurse" would mean
273 that it points back to this object. E.g. "recurse^^^" means it points
274 to a structure three layers up. For doubly-linked list, the pointer
275 to the previous element is of course the one that has been just
276 expanded in the previous round, and therefore all of them are either
277 recurse^, or nil. If the next and previous pointers are swapped, the
278 output adjusts correspondingly:
281 ll({ 9, nil, { 8, recurse^, { 7, recurse^, { 6, ..., ... } } } })
287 Ltrace has support for some elementary expressions. Each expression
288 can be either of the following:
296 Value of \fINUM\fR-th argument. The expression has the same value as
297 the corresponding argument. \fBarg1\fR refers to the first argument,
298 \fBarg0\fR to the return value of the given function.
302 Return value of function, same as \fBarg0\fR.
306 Value of \fINUM\fR-th element of the surrounding structure type. E.g.
307 \fBstruct(ulong,array(int,elt1))\fR describes a structure whose first
308 element is a length, and second element an array of ints of that
316 Describes array which extends until the first element, whose each byte
317 is 0. If an expression is given, that is the maximum length of the
318 array. If NUL terminator is not found earlier, that's where the array
324 Sometimes the actual function prototype varies slightly depending on
325 the exact parameters given. For example, the number and types of
326 printf parameters are not known in advance, but ltrace might be able
327 to determine them in runtime. This feature has wider applicability,
328 but currently the only parameter pack that ltrace supports is
329 printf-style format string itself:
333 When \fBformat\fR is seen in the parameter list, the underlying string
334 argument is parsed, and GNU-style format specifiers are used to
335 determine what the following actual arguments are. E.g. if the format
336 string is "%s %d\\n", it's as if the \fBformat\fR was replaced by
337 \fBstring, string, int\fR.
341 C functions often use one or more arguments for returning values back
342 to the caller. The caller provides a pointer to storage, which the
343 called function initializes. Ltrace has some support for this idiom.
345 When a traced binary hits a function call, ltrace first fetches all
346 arguments. It then displays \fIleft\fR portion of the argument list.
347 Only when the function returns does ltrace display \fIright\fR portion
348 as well. Typically, left portion takes up all the arguments, and
349 right portion only contains return value. But ltrace allows you to
350 configure where exactly to put the dividing line by means of a \fB+\fR
351 operator placed in front of an argument:
354 .B int\fR asprintf\fB(+string*, format);
357 Here, the first argument to asprintf is denoted as return argument,
358 which means that displaying the whole argument list is delayed until
359 the function returns:
362 a.out->asprintf( <unfinished ...>
364 libc.so.6->malloc(100) = 0x245b010
366 [... more calls here ...]
368 <... asprintf resumed> "X=1", "X=%d", 1) = 5
371 It is currently not possible to have an "inout" argument that passes
372 information in both directions.
376 In the following, the first is the C prototype, and following that is
377 ltrace configuration line.
380 .B void\fR func_charp_string\fB(char\fR str\fB[]);
381 .B void\fR func_charp_string\fB(string);
384 .B enum\fR e_foo \fB{\fRRED\fB, \fRGREEN\fB, \fRBLUE\fB};
386 .B void\fR func_enum\fB(enum\fR e_foo bar\fB);\fR
388 .B void\fR func_enum\fB(enum(\fRRED\fB,\fRGREEN\fB,\fRBLUE\fB));\fR
392 .B typedef\fR e_foo \fB= enum(\fRRED\fB,\fRGREEN\fB,\fRBLUE\fB);\fR
394 .B void\fR func_enum\fB(\fRe_foo\fB);\fR
398 .B void\fR func_arrayi\fB(int\fR arr\fB[],\fR int len\fB);
399 .B void\fR func_arrayi\fB(array(int,arg2)*,int);
402 .B struct\fR S1 \fB{float\fR f\fB; char\fR a\fB; char \fRb\fB;};
404 .B struct\fR S2 \fB{char\fR str\fB[\fR6\fB]; float\fR f\fB;};
406 .B struct\fR S1 func_struct\fB(int \fRa\fB, struct \fRS2\fB, double \fRd\fB);
408 .B struct(float,char,char)\fR func_struct\fB(int, struct(string(array(char, \fR6\fB)),float), double);
412 Petr Machata <pmachata@redhat.com>