Announcing a new utility: 'trace'

* flags demangling (see the mmap example);
* pretty-printing of the standard types, see various strace examples:
rt_sigaction(SIGRTMIN, {0x7fe36e983860, [], SA_RESTORER|SA_SIGINFO, 0x7fe36e98cf60}, NULL, 8) = 0
stat("/usr/bin/test", {st_mode=S_IFREG|0755, st_size=30136, ...}) = 0
* see through buffers (strace -s) for reads and writes (it's *VERY* useful to detect off-by-ones in read(v)s/write(v)s/{send,recv}{,msg} and so forth (I've used it numerous times);
* CMSG decoding (for example for the SCM_CREDENTIALS or SCM_RIGHTS stuff for unix sockets).

Argument names are good though, and useful for the reader for less used functions (or raw kernel syscalls that the libc usually wraps in more known interfaces e.g.).

I know "trace" can do stuff that strace doesn't like reporting what was slow, filter the trace for many things. But it cannot claim to replace strace until it can do that. Strace is (for me) more used for debugging purposes (What does my $KJASD*(*@!#*&!@ program is doing with the syscalls because I'm too dumb to understand what is happening by reading the code) than for performance reasons (even if did use it one or twice to do that with post-filtering of strace -tt output, clearly painful and here "trace" is a clear winner).

Right now trace is a *very interesting* performance oriented trace tool, on the way to take some "market share" to strace, but it's not a drop in replacement by far.