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
pgptONwYHIzVl.pgp
Description: PGP signature
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
