Re: rpctrace output improvements?

[Sergey Bugaev]

On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
> > * Symbolicated flags and file paths (potentially, also proc and auth 
> > handles)
>
> For file path it'll probably be much harder since there can be several
> path (or even no path!) for a given file port.

And as far as I can see, there's no RPC to get the parent directory of
a file. I can do that for a dir with dir_lookup ("..") (and that's
what _hurd_canonicalize_directory_name_internal () uses), but it won't
work with arbitrary files.

So my plan is to use _hurd_canonicalize_directory_name_internal ()
with directories (previously unknown ports when they're used as a
request port in a dir_* RPC), and take note of file paths as file
ports are received from dir_lookup (). This should catch all files
that the tracee opens; but not any fds it inherits. This should not be
a big deal though; since when using rpctrace std{in,out,err} will
typically be the terminal, and for those we can always get a name.

Of course, there'd always be a fallback: if we see an unrecognized
flag value, or a port we cannot symbolicate, we'd just print its raw
value (as now).

> > and injecting errors (very useful for testing all error handling code
> > paths).
>
> That's probably a bit tricky to express.

I was thinking it'd use the same format as strace, e.g.
--inject=file:error=ENOENT:when=9..10 (inject ENOENT into the 9th and
10th syscalls from the "file" group).

Sergey

P. S. Could you please take a look at my glibc patches in the other thread?