1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
-*-org-*-
* TODO
** Automatic prototype discovery:
*** Use debuginfo if available
Alternatively, use debuginfo to generate configure file.
*** Demangled identifiers contain partial prototypes themselves
** Automatically update list of syscalls?
** Improve documentation
*** Describe syntax of config files
** Update /etc/ltrace.conf
In particular, we could use a config directory, where packages
would install their ltrace config scripts. The config file could
be named after SONAME, and automatically read when corresponding
library is mapped.
** More operating systems (solaris?)
** Get rid of EVENT_ARCH_SYSCALL and EVENT_ARCH_SYSRET
** Implement displaced tracing
A technique used in GDB (and in uprobes, I believe), whereby the
instruction under breakpoint is moved somewhere else, and followed
by a jump back to original place. When the breakpoint hits, the IP
is moved to the displaced instruction, and the process is
continued. We avoid all the fuss with singlestepping and
reenablement.
** Create different ltrace processes to trace different children
** Config file syntax
*** typedef should be able to assign a lens to a name
*** format should take arguments like string does
** More fine-tuned control of right arguments
Combination of named arguments and some extensions could take care
of that:
| void func(X=hide(int*), long*, +pack(X)); |
This would show long* as input argument (i.e. the function could
mangle it), and later show the pre-fetched X. The "pack" syntax is
utterly undeveloped as of now. The general idea is to produce
arguments that expand to some mix of types and values. But maybe
all we need is something like
| void func(out int*, long*); |
ltrace would know that out/inout/in arguments are given in the
right order, but left pass should display in and inout arguments
only, and right pass then out and inout. + would be
backward-compatible syntactic sugar, expanded like so:
| void func(int*, int*, +long*, long*); |
| void func(in int*, in int*, out long*, out long*); |
But sometimes we may want to see a different type on the way in and
on the way out. E.g. in asprintf, what's interesting on the way in
is the address, but on the way out we want to see buffer contents.
Does something like the following make sense?
| void func(X=void*, long*, out string(X)); |
* BUGS
** After a clone(), syscalls may be seen as sysrets in s390 (see trace.c:syscall_p())
|
