RFC: path display and path filtering features.

[Grant Edwards]

Attached is a patch against 4.5.20 that adds two new command line
options:

 -y  Attempt to display paths associated with file descriptor
     arguments.

 -P <pathlist>

     Display only system calls accessing one of the paths in the
     specified colon-separated path list.

The features above depend on added code that attempts to track the
state of the traced process's fd table based on the observed
open/close/dup/clone system calls.  Another approach would be to do a
readlink() on /proc/<pid>/fd/<fd> every time we handle a system call
with a file descriptor argument.  I decided against the readlink()
approach in order to avoid the additional overhead and to provide a
workable solution on systems that don't have /proc/<pid>/fd links
available.

The attached code does use the "readlink() on /proc" mechanism to
initialize the fd state when attaching to an already-running pid, but
after that it maintains fd/path info based on observed open/close/dup
system calls.  This implies that the new features may be of limited
use when attaching to an already-running process on a system that
doesn't have /proc/<pid>/fd/<fd> links.

While the attached patch currently meets all of my requirements, there
are areas where it would need to be improved before it could be
merged into the repository:

 1) Support for non-Linux OSes isn't done yet.  For example, the
    handling of the clone system call where it is determined whether
    to copy or share the descriptor state assumes the OS is Linux.

 2) It is assumed that TRACE_DESCRIPTOR means arg[0] is a file
    descriptor, and that TRACE_FILE means arg[0] is path.  That's not
    100% accurate, but so far it's close enough for all of my use
    cases.

 3) The code that tracks fd table state is invoked even if paths are
    neither being displayed nor filtered-upon.  That means that the
    handling of a few system calls (e.g. open/close/dup) takes
    slightly longer than it needs to in the cases where neither of the
    two new options is being used.

 4) I have no idea how portable the readlink() on /proc/<pid>/fd/<fd>
    mechanism is, or if there are alternative mechanisms for other OSes.

 5) The indentation needs to be fixed.  I ran all the sources through
    indent in order to get them consistent before I started work, and
    the attached diffs were done after everything was re-indented.
    
 6) There are probably some more obsure ways to associate an fd with a
    path that I haven't caught (for example, the fcntl DUPFD operations).

 7) Though descriptors with the close-on-exec flag set aren't handled
    properly, the path will get replaced when the child process does
    associate a new file with the file descriptor.
    
If, with some additional work, the new options would be accepted, then
I'd be happy to work on addressing these (or other) issues.

OTOH, if nobody else is interested in the new features (and I'm going
to have to maintain my own fork/patchset) then there's no point in me
doing anything further since the current patchset meets all of my
requirements.

Thoughts?

-- 
Grant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pathtrace.patch
Type: application/patch
Size: 30918 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110214/0eaf42f2/attachment.bin>