| |||||||||||||
Announcing a new utility: 'trace'Announcing a new utility: 'trace'Posted Nov 17, 2010 13:24 UTC (Wed) by jdahlin (guest, #14990)In reply to: Announcing a new utility: 'trace' by nix Parent article: Announcing a new utility: 'trace' LD_AUDIT looks like a nice interface, haven't heard about it before. However, I think you're confusing ltrace with latrace, only the latter uses the LD_AUDIT interface.
(Log in to post comments)
Announcing a new utility: 'trace' Posted Nov 17, 2010 18:16 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh, er, yes, I was. I'm not sure I ever encountered ltrace. :)
Announcing a new utility: 'trace' Posted Nov 17, 2010 19:35 UTC (Wed) by oak (subscriber, #2786) [Link]
Now that the latest latrace version has fixed the process stack handling crashes and the output can be toggled on & off[1], it's more useful than ltrace.
[1] The latrace based tracing downside is that you need to start the process under latrace as it's depending on dynamic linker (LD_AUDIT-feature) whereas ltrace can be attached to an already running process.
Downsides of ptrace() based ltrace are that it doesn't work for threaded processes[2] and that it cannot trace library -> library calls, only binary -> library calls. Both are pretty huge downsides.
[2] ltrace toggles the breakpoints to let programs continue, this means that it can miss other threads calling same functions at the same time. Whereas e.g. functracer executes the instruction that was under breakpoint out-of-line (i.e. needs arch-specific code to emulate code using relative addressing) so that it doesn't need to be disabled.
One more problem with ltrace & functracer are that Linux ptrace() is somewhat broken for tracing. Utrace is supposed to fix/make ptrace() robust, but unfortunately it's still not in mainline.
|
|||||||||||||