Page MenuHomeFreeBSD

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

Authored by bdrewery on Oct 5 2015, 7:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 14, 5:51 PM
Unknown Object (File)
Jan 5 2024, 4:52 AM
Unknown Object (File)
Jan 5 2024, 4:51 AM
Unknown Object (File)
Jan 5 2024, 4:51 AM
Unknown Object (File)
Jan 5 2024, 4:51 AM
Unknown Object (File)
Jan 5 2024, 4:50 AM
Unknown Object (File)
Jan 5 2024, 4:50 AM
Unknown Object (File)
Jan 5 2024, 4:50 AM
Subscribers

Details

Reviewers
jhb
Group Reviewers
manpages
Commits
rS288957: truss: Add support for utrace(2).
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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

bdrewery retitled this revision from to Add utrace(2) support using kdump(1)'s decoding..
bdrewery updated this object.
bdrewery edited the test plan for this revision. (Show Details)
bdrewery added a reviewer: 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 marked 2 inline comments as done.
bdrewery edited edge metadata.

Fix findings.

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

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.

In D3819#78970, @jhb 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?

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

This revision was automatically updated to reflect the committed changes.