Better tracing of network calls [was Re: GSOC candidature draft for urgent feedback]

[Philippe Ombredanne]

On Tue, Feb 25, 2014 at 8:49 PM, enh <enh at google.com> wrote:
> actually, -y was my biggest wish-list feature :-)
>
> other things i've hated doing manually in the past include working out
> exactly what a given socket is (usually "what's the remote address?").
> pipes too. in both cases the default /proc format is somewhat helpful
> but really only the first piece of the puzzle if you actually want to
> know what's on the other end.

Elliott:
FYI, the tracing of sockets was partial until recently and has been
updated in head such that socket descriptors are consistently reported
as opposed to only get a descriptor number in some cases.
You should give a shot to the latest master
This is a first step.

There have also been some discussions here:
https://sourceforge.net/p/strace/mailman/message/32044240/
and adding details on the host:port protocol of a socket could be part
of a GSOC project idea for advanced path decoding as suggested by
Dmitry.

On the pipes side, I am a bit more puzzled as what more could be done....

pipe(2) has nothing we could decode afaik?

Are you talking about decoding more of dup(2) dup2/3 and fcntl(2) with
F_DUPFD  when there is a pipe involved?

I think that for pipes the only thing that can be done on a per
syscall is to have a the pipe fd... and that tracing what went into
the pipe is only something that can be done by reasoning not on a
single syscall but across multiple calls and eventually multiple
processes, in effect parsing a whole strace output, or is there
something you think could be done at the syscall level?


-- 
Philippe Ombredanne