Add support for displaying thread IDs to truss(1).
ClosedPublic
Actions

Authored by jhb on Feb 20 2016, 6:59 AM.

Details

Reviewers

kib
bdrewery

Group Reviewers

manpages

Commits

rS295930: Add support for displaying thread IDs to truss(1).

Summary

Add support for displaying thread IDs to truss(1).

Consolidate duplicate code for printing the metadata at the start of each line into a shared function.
Add an -H option which will log the thread ID of the relevant thread for each event.

Test Plan

truss a simple program that creates threads and has them all die due to a trap in one of the threads (this does not log interrupted system calls when the threads are killed by the kernel)
truss a simple program that creates threads that all gracefully exit (this logs thr_exit() calls)
truss a simple program that forks a child process to regression test -f
test attaching to the first two threaded programs while paused to ensure all threads report events properly after the pause.
truss a simple program that creates a thread and then calls exec to ensure the implicit exit of the extra thread is logged

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

jhb updated this revision to Diff 13542.Feb 20 2016, 6:59 AM

jhb retitled this revision from to Improve support for threads in truss(1)..

jhb updated this object.

jhb edited the test plan for this revision. (Show Details)

jhb added reviewers: bdrewery, kib.

Herald added a reviewer: manpages. · View Herald TranscriptFeb 20 2016, 6:59 AM

Herald added a subscriber: imp. · View Herald Transcript

kib added inline comments.Feb 20 2016, 3:01 PM

usr.bin/truss/setup.c
182 ↗	(On Diff #13542)	Indeed, it will kill the traced processes. Why not to call detach_proc() for each ? A truss-specific variant of err() would be handy there, I do not think that doing this in atexit() handler is wise. This would be, of course, for other change.

In general I think I also want to split this up. The -H flag doesn't depend on LWP events and could be MFC'd, so I think I will pull that out into a separate change to do first and then revisit the LWP event part of this.

usr.bin/truss/setup.c
182 ↗	(On Diff #13542)	Truss does do this if it catches a signal. I could add more stuff here, but in practice these events should never happen. It's basically an assertion that is always enabled and prints a nicer error on failure. I'm a bit hesitant to expend a lot of effort to clean up after an error that should never occur.
441 ↗	(On Diff #13542)	I realized this morning that my logic here actually isn't correct. In particular, if two threads both call exit() only one of them "wins" and should have the call reported. For process exit this should always be correct as we get CLD_EXITED when the exit happens due to a system call, and there is only one thread left when CLD_EXITED is reported. However, for a PL_FLAG_EXITED event, there is currently no way to distinguish thread exit reasons. I see a couple of options: Use a magic "ret_type" of -1 for thr_exit() (and the equivalent function for the Linux ABI if it isn't "exit") in the syscall table. This is a bit hackish, but expedient. Alter how ptrace reports thread exit events due to a system call calling kern_thr_exit() vs thread_suspend_check() killing a thread due to a single threading request. This requires a kernel change. Just don't bother trying to report thr_exit() system calls and only report the exit for process exit.