RFC: path display and path filtering features.

[Grant Edwards]

On 2011-02-15, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Mon, Feb 14, 2011 at 02:44:29PM -0600, Grant Edwards wrote:
>> 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.
>
> This feature looks promising, I'd like to have it implemented in strace.
> I'm not sure about option name; at least, the link between -y and its
> effect is not obvious to me.

All the good letters were taken. :)

>>  -P <pathlist>
>> 
>>      Display only system calls accessing one of the paths in the
>>      specified colon-separated path list.
>
> I think colon-separated path list is not quite convenient; from user
> point of view, I'd prefer to specify one path per option, like -p.

At the time I hadn't noticed how -p worked, and the colon-separated
path list is a common Unix notation.  I'll change -P to work the same
way (it's actually simpler to implement than the colon-separated 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 approach to track descriptors is much more complicated (and
> therefore more error-prone) and less reliable than readlink-based
> because of all details that have to be taken into account to trace
> descriptors properly.

True.

> The overhead of readlink-based method is one syscall per descriptor,
> that's hardly noticeable compared to multiple syscalls strace already
> does to parse a single syscall made by the target process.

I was wondering about that.  I didn't realized until later that it
takes an additional system call for each "indirect" parameter, as well
as a context switch on both entry and exit of the system call.  Adding
a read of /proc is probably negligible.  It would limit usage to
systems with /proc enabled.  That's probably not a big issue unless
you're talking about small embedded systems.  It would be nice if the
read didn't have to happen twice (once when deciding to display the
syscall, and a second time when displaying it), but trying to cache
the value also introduces complications.

>> 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.
>
> I wouldn't bother of non-Linux OSes.  There are no feedback from these
> OSes at all, so lets place the feature under #ifdef LINUX and leave
> non-Linux case to people who care about strace on non-Linux.

Will do.

-- 
Grant