Add utrace(2) support using kdump(1)'s decoding.

[bdrewery]

Summary

This utilizes the kdump utrace decoding in a dirty way. A libkdump or
something may be warranted.

Output:

Unknown:

utrace({ 24: 50 ec d4 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }) = 0 (0x0)

Malloc with MALLOC_CONF=utrace:true

utrace({ 0x801a18040 = malloc(26) })             = 0 (0x0)
utrace({ 0x801a18060 = malloc(24) })             = 0 (0x0)
utrace({ free(0x801a18040) })                    = 0 (0x0)

RTLD with LD_UTRACE=1:

utrace({ RTLD: loaded   0x8007ef400 @ 0x8009ed000 - 0x800ca5fff (/usr/lib/libc++.so.1) }) = 0 (0x0)
utrace({ RTLD: loaded   0x8007ef800 @ 0x800ca6000 - 0x800ec2fff (/lib/libcxxrt.so.1) }) = 0 (0x0)
utrace({ RTLD: loaded   0x8007efc00 @ 0x800ec3000 - 0x8010ecfff (/lib/libm.so.5) }) = 0 (0x0)
utrace({ RTLD: loaded   0x8007f8000 @ 0x8010ed000 - 0x8012fafff (/lib/libgcc_s.so.1) }) = 0 (0x0)
utrace({ RTLD: loaded   0x8007f8400 @ 0x8012fb000 - 0x80169dfff (/lib/libc.so.7) }) = 0 (0x0)
utrace({ RTLD: init 0x801333018 for 0x8007f8400 (/lib/libc.so.7) }) = 0 (0x0)
utrace({ RTLD: init 0x8010eefa0 for 0x8007f8000 (/lib/libgcc_s.so.1) }) = 0 (0x0)
utrace({ RTLD: init 0x800ec7610 for 0x8007efc00 (/lib/libm.so.5) }) = 0 (0x0)
utrace({ RTLD: init 0x800cadc58 for 0x8007ef800 (/lib/libcxxrt.so.1) }) = 0 (0x0)
utrace({ RTLD: init 0x800a26268 for 0x8007ef400 (/usr/lib/libc++.so.1) }) = 0 (0x0)
utrace({ RTLD: init 0x4032b0 for 0x8007ef000 (/usr/home/bryan/git/netplay/netplay) }) = 0 (0x0)
utrace({ dlopen(libcrypto.so.7, RTLD_LAZY | RTLD_GLOBAL) }) = 0 (0x0)
utrace({ RTLD: loaded   0x8007f8800 @ 0x801c00000 - 0x801ff6fff (/lib/libcrypto.so.7) }) = 0 (0x0)

PR: 43819 [inspired by]

Test Plan

Running truss and kdump.

[bdrewery]

Fix copyright

[bdrewery]

Update manpages.

[jhb]

If we could share the ioctl.c file that kdump and truss both use, then I think a libkdump is probably a good idea. (I'm not sure how similar the ioctl.c files are, but we could probably define an interface for them that both programs could share.)

usr.bin/truss/syscalls.c

1624 ↗

(On Diff #9172)

Spaces around +? (I think I wiped out all the previous forms of that style bug in a previous commit)

usr.bin/truss/truss.1

24 ↗

(On Diff #9172)

utrace() is a system call, so I would just leave this language as-is.

[bdrewery]

Fix findings.

[bdrewery]

In D3819#78795, @jhb wrote:

If we could share the ioctl.c file that kdump and truss both use, then I think a libkdump is probably a good idea. (I'm not sure how similar the ioctl.c files are, but we could probably define an interface for them that both programs could share.)

Yes it looks like we could share them, using a similar manner to what I've done. The only real difference is printf() vs return (str).

[jhb]

In D3819#78804, @bdrewery wrote:

In D3819#78795, @jhb wrote:

If we could share the ioctl.c file that kdump and truss both use, then I think a libkdump is probably a good idea. (I'm not sure how similar the ioctl.c files are, but we could probably define an interface for them that both programs could share.)

Yes it looks like we could share them, using a similar manner to what I've done. The only real difference is printf() vs return (str).

Ok, the return str can always be done by having the caller use open_memstream() and then passing a FILE * to the shared routine (as you did with utrace).

I've thought about this a bit more and I think we should probably not call it 'libkdump' but something more like 'libsyscall_decode' (or hopefully something shorter that conveys the same meaning). I think we could likely move
much of the 'subr.c' file in kdump into this as well to share routines with truss (e.g. decoding flags to mmap() or the like). I would probably opt for the ktrace approach when possible since it automatically adds new flags whereas each individual flag has to be added to each xlat table for truss.

[bdrewery]

In D3819#78970, @jhb wrote:

In D3819#78804, @bdrewery wrote:

In D3819#78795, @jhb wrote:

If we could share the ioctl.c file that kdump and truss both use, then I think a libkdump is probably a good idea. (I'm not sure how similar the ioctl.c files are, but we could probably define an interface for them that both programs could share.)

Yes it looks like we could share them, using a similar manner to what I've done. The only real difference is printf() vs return (str).

Ok, the return str can always be done by having the caller use open_memstream() and then passing a FILE * to the shared routine (as you did with utrace).

I've thought about this a bit more and I think we should probably not call it 'libkdump' but something more like 'libsyscall_decode' (or hopefully something shorter that conveys the same meaning). I think we could likely move
much of the 'subr.c' file in kdump into this as well to share routines with truss (e.g. decoding flags to mmap() or the like). I would probably opt for the ktrace approach when possible since it automatically adds new flags whereas each individual flag has to be added to each xlat table for truss.

Do you mind if I commit this individually, after your sort change, and then work on the libsysdecode to clean it all up?

[bdrewery]

Rebase

[jhb]

Oh, yes, that shouldn't hold this up.