I've developed a new tool based on ptrace(2) - picotrace.
(NetBSD 8.99.38 or newer is required.)
Upstream repository:
https://github.com/krytarowski/picotrace
I've packaged it in pkgsrc as devel/picotrace.
It's similar to truss from FreeBSD and strace from Linux.
ktruss(1) & friends gather logging from kernel internals.
picotrace collects information through ptrace(2) and gathered in a
userspace program directly.
Both approaches have pros and cons, the main benefit of picotrace is
that it's more flexible with checking what happens inside the process
memory.
picotrace is intended to be fully MI.
There are two main purposes of picotrace:
- craft a framework for ptrace(2)-based programs on NetBSD
- quickly draft debuggers that exercise the kernel
Example usage.
http://netbsd.org/~kamil/picotrace/nested_fork.txt (forks)
http://netbsd.org/~kamil/picotrace/thrd_create.txt (threads)
Documentation.
http://netbsd.org/~kamil/picotrace/picotrace.html1
picotrace is a framework that is intended to be reused in new programs.
I have got a local tracer based on this template with scripting in Lua
that performs pretty printing of syscall arguments.
$ ./picotrace -f ./ustrace.lua echo |grep open|grep SCE|head -3
6838 1 echo SCE open("/etc/ld.so.conf",O_RDONLY)
6838 1 echo SCE open("/usr/local/lib/libc.so.12",O_RDONLY)
6838 1 echo SCE open("/lib/libc.so.12",O_RDONLY)
or:
$ ./picotrace -f ./ustrace.lua echo |grep mmap|grep SCE|head -3
29204 1 echo SCE mmap(0, 0x8000, PROT_WRITE,
MAP_PRIVATE, 0xffffffff, 0 {PAD FIELD}, 0)
29204 1 echo SCE mmap(0, 0x1000, PROT_READ, MAP_SHARED,
0x3, 0 {PAD FIELD}, 0)
29204 1 echo SCE mmap(0, 0x614000, PROT_EXEC,
MAP_PRIVATE, 0x3, 0 {PAD FIELD}, 0)
(This Lua version integration is still in a local draft, not ready for
sharing.)
I'm not sure if this is the right tool for the task of writing a
truss-like program in Lua with all the arguments decoding in Lua. In
general performing bit operations, accessing C header constants,
structs, converting between types etc is convoluted in Lua. I'm not
trying to even think about performance impact of my code...
On the other hand Lua is quite hackable whenever we want dynamic
scripting rules with a restricted number of operations.
Before going for performance and features there are still instabilities
of the ptrace(2) API. Some of the issues are easily triggerable by the
current version of picotrace and it means that it does its job as
intended. I've caught at least one new suspicious behavior that will be
investigated. I'm just 'iterating' with picotrace through the life time
of a real-world process and catch misbehaving program if something goes
wrong (usually hang).
Attachment:
signature.asc
Description: OpenPGP digital signature