RFC: path display and path filtering features.

[Dmitry V. Levin]

On Thu, Feb 17, 2011 at 11:29:27AM -0600, Grant Edwards wrote:
> I've re-written the path display/trace features.  Attached is a
> snapshot of the diffs against the current git HEAD.  Changes since the
> first version I posted follow:

Thanks a lot.  Now we have a working PoC to discuss details.

>  * Removed the code that tracked fd-table state based on syscalls.  It
>    now does a readlink() on /proc/<pid>/fd/<fd> to find the path
>    associated with a file descriptor.

Linux kernel treats file descriptors as unsigned integers, but
sysctl_nr_open is still limited to 0x100000, so I'd add an extra check
for fd < 0 in getpath().

>  * Change the -P option so that instead of accepting a colon-separated
>    list of paths, it accepts a single path.  Multiple -P options can
>    be specified to trace multiple paths.

Maybe an attempt to exceed MAXSELECTED in pathtrace_select() should be
treated as a fatal error.

>  * Change the way that file descriptors are printed by the display
>    functions.  Instead of using "%s" and a function that returns a
>    formatted string, they now use a printfd() function analogous to
>    the printpath() function.

BTW, there is a long standing bug in decoding of file descriptors on
64bit architectures, and it's time to fix it in one place.

For example,
$ cat close.c
int close(unsigned long fd);
int main(void){return !!close(0xffffffff00000000UL);}
$ gcc -Wall -O2 close.c -o close
$ strace -eclose -o'|tail -1' ./close
close(-4294967296)                      = 0
$ strace -y -eclose -o'|tail -1' ./close
close(-4294967296</dev/pts/1>)          = 0

The fix is to change "fd" type in printfd() from long to int, and to print
it using %d format.

>  * Added handling (for Linux) for system calls where we need to look
>    at something other than arg[0] for a descriptor/path.

There is a lot of work to do.
Some non-arg[0] syscalls are not listed in pathtrace_match(); for
example, sys_dup3 and sys_old_mmap are listed but sys_dup2 and
sys_mmap are not.
Some struct sysent records still have outdated sys_flags; for example,
TRACE_DESC is not set for sys_mmap and sys_fadvise64*.

I'm not sure that we can ignore all cases where syscalls return file
descriptor as their return value.  For example,
$ strace -s4 -y -P /lib64/libc-2.11.3.so -P /lib64/libc.so.6 /bin/echo
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3</lib64/libc-2.11.3.so>, "\177ELF"..., 832) = 832
fstat(3</lib64/libc-2.11.3.so>, {st_mode=S_IFREG|0755, st_size=1465744, ...}) = 0
close(3</lib64/libc-2.11.3.so>)         = 0

The pathname passed to open(2) is a symlink, and /proc/<pid>/fd/<fd>
points to the canonicalized pathname, so -P /lib64/libc-2.11.3.so
won't catch this open(2) call now.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110218/d66ef3e9/attachment.bin>