| |||||||||||||
Announcing a new utility: 'trace'Announcing a new utility: 'trace'Posted Nov 16, 2010 23:22 UTC (Tue) by tglx (subscriber, #31301)In reply to: Announcing a new utility: 'trace' by foom Parent article: Announcing a new utility: 'trace'
We know that and for one this can be improved, but OTOH our main objective at the moment was to provide features which are not in strace (and never will be): The analysis of blocking events, pagefaults etc.
This is just the rough start of this tool and we are happy to listen to your feedback!
Thanks,
tglx
(Log in to post comments)
Announcing a new utility: 'trace' Posted Nov 16, 2010 23:48 UTC (Tue) by foom (subscriber, #14868) [Link]
If there's no technical or philosophical impediment to their reimplementation in the future: Awesome!
I'm certainly looking forward to all those other features -- they are sorely needed, and it makes total sense to work on the unique features first. Indeed I've been wishing for a tool which would easily tell me what pages I'm faulting in (and in what order) out of a 5GB mmaped file, in order to help debug performance issues with disk seeks when the file is totally paged out.
I just hope that in time, the existing featureset of strace can also be supported, so that we don't end up with two half-useful tools instead of one awesome tool.
Announcing a new utility: 'trace' Posted Nov 17, 2010 12:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Strongly agreed. strace *is* a crufty old goat that would be nice to replace, and anything that can put ptrace() uses to death is a good thing in my eyes. But we do need argument decoding if we're to use it to figure out what on earth a program is up to, which is, y'know, the point of it. AIX has a syscall trace program that doesn't do any argument decoding (even of strings!), and it's main use is as a source of frustration (though of course it doesn't do any of the other things trace does either). Kicking up the debugger is often easier, even without debugging information.
(I know that argument decoding is really boring to get right and tends to involve giant tables of syscalls so needs active maintenance, but unfortunately it's also hard to avoid for a useful tool. But, hey, if you don't actually object to it so it might turn up later, that's fine: we know there's nothing in the implementation that makes it harder for trace than it is for strace. At least you don't need to worry too much about putting new syscalls in fast: the new syscalls will be relatively unused for a long time, so you don't need to rush to add them to the syscall table in the tracing tool.)
Announcing a new utility: 'trace' Posted Nov 26, 2010 2:33 UTC (Fri) by kabloom (guest, #59417) [Link]
Hey! Since `trace' lives in the kernel tree, this means that all of the syscall decoding code will ALSO live in the kernel tree, and that whoever writes a new syscall can be asked to provide the decoder at the same time.
Announcing a new utility: 'trace' Posted Nov 20, 2010 17:01 UTC (Sat) by kleptog (subscriber, #1183) [Link]
Anything that brings something like strace but better is good. However, if you do decide to do argument decoding I strongly suggest looking at the source for strace. It contains scripts for dozens of OSes and architechtures for extracting syscall, ioctl and signal information. Along with code to print it out.
It's probably a good idea to at least glance at it once in a while to make sure the impedance mismatch doesn't get too great, so that when you do want it it won't be much work.
(The PORTING document of strace suggests that you should be able to create a new event loop and you'll have a basic working version pretty quick.)
|
|||||||||||||