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).
