Adapt ASLR to ltrace
[platform/upstream/ltrace.git] / TODO
diff --git a/TODO b/TODO
index acee057..af1198c 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,15 +1,17 @@
 -*-org-*-
 * TODO
+** Keep exit code of traced process
+   See https://bugzilla.redhat.com/show_bug.cgi?id=105371 for details.
+
 ** Automatic prototype discovery:
 *** Use debuginfo if available
     Alternatively, use debuginfo to generate configure file.
-*** Demangled identifiers contain partial prototypes themselves
+*** Mangled identifiers contain partial prototypes themselves
+    They don't contain return type info, which can change the
+    parameter passing convention.  We could use it and hope for the
+    best.  Also they don't include the potentially present hidden this
+    pointer.
 ** Automatically update list of syscalls?
-** 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
    reenablement.
 ** Create different ltrace processes to trace different children
 ** Config file syntax
+*** mark some symbols as exported
+    For PLT hits, only exported prototypes would be considered.  For
+    symtab entry point hits, all would be.
+
 *** named arguments
     This would be useful for replacing the arg1, emt2 etc.
 
 
     Perhaps we should hook to something after all.
 
+*** system call error returns
+
+    This is closely related to above.  Take the following syscall
+    prototype:
+
+    | long read(int,+string0,ulong);
+
+    string0 means the same as string(array(char, zero(retval))*).  But
+    if read returns a negative value, that signifies errno.  But zero
+    takes this at face value and is suspicious:
+
+    | read@SYS(3 <no return ...>
+    | error: maximum array length seems negative
+    | , "\n\003\224\003\n", 4096)                  = -11
+
+    Ideally we would do what strace does, e.g.:
+
+    | read@SYS(3, 0x12345678, 4096)                = -EAGAIN
+
 *** errno tracking
     Some calls result in setting errno.  Somehow mark those, and on
-    failure, show errno.
+    failure, show errno.  System calls return errno as a negative
+    value (see the previous point).
 
 *** second conversions?
     This definitely calls for some general scripting.  The goal is to
     | void func(int*, int*, +long*, long*);              |
     | void func(in int*, in int*, out long*, out long*); |
 
+    This is useful in particular for:
+
+    | ulong mbsrtowcs(+wstring3_t, string*, ulong, addr); |
+    | ulong wcsrtombs(+string3, wstring_t*, ulong, addr); |
+
+    Where we would like to render arg2 on the way in, and arg1 on the
+    way out.
+
     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.
    according to architecture rules.  Maybe this could be achieved by a
    per-arch config file with typedefs such as:
 
-   | typedef ulong = uint8_t |
+   | typedef ulong = uint8_t; |
+
+** Support for ARM/AARCH64 types
+   - ARM and AARCH64 both support half-precision floating point
+     - there are two different half-precision formats, IEEE 754-2008
+       and "alternative".  Both have 10 bits of mantissa and 5 bits of
+       exponent, and differ only in how exponent==0x1F is handled.  In
+       IEEE format, we get NaN's and infinities; in alternative
+       format, this encodes normalized value -1S × 2¹⁶ × (1.mant)
+     - The Floating-Point Control Register, FPCR, controls: — The
+       half-precision format where applicable, FPCR.AHP bit.
+   - AARCH64 supports fixed-point interpretation of {,double}words
+     - e.g. fixed(int, X) (int interpreted as a decimal number with X
+       binary digits of fraction).
+   - AARCH64 supports 128-bit quad words in SIMD
 
 ** Some more functions in vect might be made to take const*
    Or even marked __attribute__((pure)).
 
+** pretty printer support
+   GDB supports python pretty printers.  We migh want to hook this in
+   and use it to format certain types.
+
+** support new Linux kernel features
+   - PTRACE_SIEZE
+   - /proc/PID/map_files/* (but only root seems to be able to read
+     this as of now)
+
 * BUGS
 ** After a clone(), syscalls may be seen as sysrets in s390 (see trace.c:syscall_p())
+** leak in regex matching
+   >> I looked into this. Ltrace is definitely leaking it. The regex is
+   >> released when filter_destroy() calls filter_rule_destroy(), but those
+   >> are not called by anything.
+   >
+   >Ah, there we go.  I just saw that we call regfree, but didn't check
+   >whether we actually call those.  Will you roll this into your change
+   >set, or should I look into it?
+
+   I'd rather you looked at it, if you don't mind.
+
+** unconditional follow of pthread_create
+
+   Basically we'd like to follow pthread_create always, and fork only if -f
+   is given.  ltrace now follows nothing, unless -f is given, and then it
+   follows everything.  (Really it follows everything alway and detaches
+   from newly-created children unless -f is given.)
+
+   The thing is, in Linux, we can choose to follow only {v,}forks by
+   setting PTRACE_O_TRACE{V,}FORK.  We can also choose to follow all clones
+   by setting PTRACE_O_TRACECLONE, but that captures pthread_create as well
+   as fork (as all these are built on top of the underlying clone system
+   call), as well as direct clone calls.
+
+   So what would make sense would be to tweak the current logic to only
+   detach if what happened was an actual fork, which we can tell from the
+   parameters of the system call.  That might provide a more useful user
+   experience.  Tracing only a single thread is problematic anyway, because
+   _all_ the threads will hit the breakpoints that ltrace sets anyway, so
+   pre-emptively tracing all threads is what you generally need.