RFC: path display and path filtering features.
grant.b.edwards at gmail.com
Mon Feb 14 20:44:29 UTC 2011
Attached is a patch against 4.5.20 that adds two new command line
-y Attempt to display paths associated with file descriptor
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
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 is a file
descriptor, and that TRACE_FILE means arg is path. That's not
100% accurate, but so far it's close enough for all of my use
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 30918 bytes
Desc: not available
More information about the Strace-devel