rpctrace output improvements?

[Sergey Bugaev]

Hello,

I use rpctrace a lot, but I'm not particularly fond of its output
format. Other tracing tools, like strace [0] on Linux and Darling's
xtrace [1] can symbolicate many flags and structures, producing
something that looks much closer to C code, and comprehensible at a
glance.

[0]: https://strace.io/
[1]: https://docs.darlinghq.org/contributing/debugging.html#xtrace

I thought I'd look if I could start implementing the same for
rpctrace. Here's sample rpctrace output:

  111<--144(pid1004)->dir_lookup ("proc/loadavg" 1 0) = 0 1 "loadavg"
  163<--162(pid1004)
task133(pid1004)->mach_port_mod_refs (pn{ 21} 0 1) = 0
  163<--162(pid1004)->dir_lookup ("loadavg" 1 0) = 0 1 ""    165<--158(pid1004)

I was thinking it could look like this instead (mock-up):

dir_lookup (file 111 (/), "proc/loadavg", O_READ, 0) ->
FS_RETRY_NORMAL, "loadavg", file 163 (/proc)
mach_port_mod_refs (task 133 (pid 1004), pn 21, MACH_PORT_RIGHT_SEND,
1) = KERN_SUCCESS
dir_lookup (file 163 (/proc), "loadavg", O_READ, 0) ->
FS_RETRY_NORMAL, "", file 165 (/proc/loadavg)

The few changes I've made here are:
* Moved the request port into the parens, like in C and MIG
* Added commas
* Replaced = with -> for denoting out params
* Dropped the 0 return code, except when there are no out params
* Symbolicated flags and file paths (potentially, also proc and auth handles)
* Some other misc tweaks to how ports are represented

I have started working on implementing this; but thought I'd ask for
feedback first. What do you think, does this sound worthwhile? Perhaps
you like some of the proposed changes but not others? Or is this a
terrible idea that I should forget about?

Sergey

P. S. There are other interesting features that we could copy from
strace, such as dynamically attaching to a process (I bet that would
be fun to implement!), tracing a subset of all calls (maps very well
to different RPC subsystems), and injecting errors (very useful for
testing all error handling code paths).