NEWS revision 69dfb0926e9b03da813e5335bf8dcab4a925b7c8
1-*-org-*-
2* Version 0.7.0
3** Tracing
4
5*** Full support for tracing multi-threaded processes
6
7    Ltrace now understands thread groups, and it stops all threads
8    before manipulating breakpoints.  The downside is that performance
9    of multi-threaded processes is rather bad, because handling any
10    event implies stopping the whole job.  The upside is that
11    individual threads don't get random SIGILL's and SIGSEGV's and
12    events are not missed.
13
14*** Support for tracing inter-library calls
15
16    -e and -x were extended to allow library selectors.  See the man
17    page for details.
18
19*** Better support for parameter passing ("fetch backend")
20
21    This version brings a more complete support for parameter passing,
22    including passing structures in registers, passing double on i386,
23    and other edge cases that were unsupported before.  The following
24    architectures now have implementation of fetch backend: x86, ppc,
25    ia64, s390, m68k.
26
27*** Awareness of deny_ptrace SELinux boolean
28
29    The deny_ptrace boolean denies all processes from being able to
30    use ptrace to manipulate other processes.  Ltrace now understands
31    that this boolean exists, and recommends turning it off, if it is
32    on and ltrace fails to attach to a process.
33
34*** Limited support for tracing returns from tail call functions
35*** -e, -x and -l selectors now allow using globs and regular expressions
36
37    See the man page for details of the selector syntax.
38
39*** Test suite can now be run under valgrind
40
41    Use --enable-valgrind to turn this on.
42
43*** [ppc] Support both BSS and secure PLTs for 32-bit processes
44*** [mips] Implement software singlestepping
45*** [mips] Add support for CPIC main programs
46*** Support tracing PIE binaries
47
48** Configuration Files
49
50*** New abstraction: parameter pack
51
52    Parameter packs make it much simpler to add specialized decoding
53    logic.  The only parameter pack currently implemented is "format"
54    for decoding printf-style format strings.  It should be relatively
55    straightforward to add more parameter packs for functions like
56    execl, strftime, and others.
57
58*** New expression: zero
59
60    When used in array length expressions, it means "this array ends
61    at the first element with zero value".  C strigs are essentially
62    array(char, zero)*.
63
64*** Lenses: change the way that underlying type is rendered
65
66    Lenses are used similarly to parametrized types, e.g.:
67    | void func(lens(int)); |
68
69**** octal
70
71     "octal", which used to be a separate type, is now lens, which can
72     be used to render any underlying type in base 8.  Plain "octal"
73     is still valid and means the same as "octal(int)".
74
75**** hex, hide, bool
76
77     Similarly, "hex" lens was introduced to format as base 16.
78     "hide" was introduced to conceal given argument.  "bool" lens was
79     added to format objects as either true, or false.
80
81**** enum
82
83     "enum" became lens as well.  Because enum already uses
84     parentheses to denote the list of enumeration values, the
85     underlying type is selected by square brackets:
86     | void func(enum[short](RED,GREEN,BLUE)); |
87
88**** string
89
90     "string" was also turned to lens.  The argument can be either a
91     char*, or pointer to array of char, or array of char.  The latter
92     is useful in cases like the following:
93     | void func_struct_2(struct(string(array(char, 6)))); |
94
95*** Misspelling of "int" as "itn" temporarily accepted, but deprecated
96
97    Pre-0.7 ltrace shipped a buggy version of ltrace.conf that
98    contained the following prototype:
99
100    | itn acl_valid(addr); |
101
102    To support extant versions of ltrace.conf, that use is now
103    considered valid, and "itn" is a synonym of "int".  It is however
104    deprecated, and will produce a warning in future.
105
106*** Using void as top-level function argument now deprecated
107
108    Functions that take no arguments shouldn't pretend to take one
109    parameter of void type.  For example the following:
110
111    | int fork(void); |
112
113    ... should be declared like this:
114
115    | int fork(); |
116
117    To support extant versions of ltrace.conf, that use is now
118    considered valid.  It is however deprecated, and will produce a
119    warning in future.
120
121*** Using void to hide one argument is now obsolete
122
123    Ltrace needs to know the exact underlying type to decide what the
124    calling convention is.  The use of void to mean "hide this
125    argument", such as the following example, is therefore obsolete:
126
127    | void func(void, array(int, arg1)); |
128
129    Instead, rewrite the prototype depending on the exact underlying
130    type:
131
132    | void func(hide(int), array(int, arg1));  |
133    | void func(hide(long), array(int, arg1)); |
134
135    To support extant versions of ltrace.conf, this use is still
136    accepted, and "void" is taken to mean "hide(int)".  It is however
137    obsolete, produces a warning, and will be removed in future.
138
139** Documentation
140
141*** New manual page ltrace.conf(5)
142*** README, INSTALL brought up to date
143*** New file CREDITS with a list of contributors
144** Bugfixes
145
146*** Fix detaching from a process
147
148    Earlier, a process that ltrace detached from would sometimes die
149    of SIGSEGV, SIGTRAP, or SIGILL.  These were caused by ltrace
150    detaching from the process just after that process hit a
151    breakpoint.  Program counter would thus be left pointing
152    mid-instruction, or signals would be left pending.
153
154*** Argument to -n is now checked for validity
155*** Fix tracing across exec in a stripped binary
156*** [x86] ORIG_RAX/ORIG_EAX may not contain original syscall number
157
158    In cases where the system call shouldn't be restarted, these are
159    set to -1.  In that case assume that the return is from the
160    topmost syscall.  This gets rid of some "unexpected breakpoint"
161    messages on x86_64 and i386.
162
163*** [ppc] Fix races in tracing -e events in 64-bit processes
164
165    As a side effect, events requested via -e now only hit when a PLT
166    call is made, which is consistent with other architectures.
167
168*** [ppc] Allow stepping over lwarx instruction
169
170** Known bugs
171
172*** [arm] Tracing is not supported at all on ARM
173
174    ltrace might work on older kernels, but no attempt was made to
175    fully support it.  Newer kernels don't support PTRACE_SINGLESTEP,
176    which ltrace depends on.  Before singlestepping is implemented in
177    software, ARM is considered unsupported.
178
179* Version 0.6.0
180
181** General Features
182
183*** Use autotools for building
184*** New option -b: disables output of signals received by the tracee
185*** New option -w: print stack trace of events
186
187    Pass --with-libunwind to configure to enable the feature.  This
188    requires libunwind.
189
190*** Support tracing of symbols from libraries opened with dlopen
191
192    These symbols are selected by -x.
193
194** Architecture-specific Changes
195
196*** Various fixes for MIPS and PowerPC
197*** Support for ARM Thumb mode
198*** Implement fetching of 5th and further function arguments on s390
199*** Support fork/exec syscalls on 31-bit s390
200*** Support for float and double arguments on x86_64
201*** Fixes for return arguments (after '+') in nested calls on x86_64
202
203* License
204-------------------------------------------------------------------------------
205Copyright (C) 2012 Petr Machata <pmachata@redhat.com>
206This file is part of ltrace.
207
208ltrace is free software; you can redistribute it and/or modify it
209under the terms of the GNU General Public License as published by the
210Free Software Foundation; either version 2 of the License, or (at your
211option) any later version.
212
213ltrace is distributed in the hope that it will be useful, but WITHOUT
214ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
215FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
216for more details.
217
218You should have received a copy of the GNU General Public License
219along with this program.  If not, see <http://www.gnu.org/licenses/>.
220