I have never really tested this, but there are issues if you
use ustack() on a 32bit app on a 64bit kernel. I had previously
written that stack walking on Linux with gcc is problematic because
of the susceptability of omit-frame-pointers meaning the only correct
way to walk a stack is via the DWARF debug records. (There is some
dwarf support in the kernel code in dtrace, but its not complete, and
theres a danger if its invoked, that bad pointers can generic
kernel GPFs).
When the user space dtrace wakes up, having fetched a buffer of info from
the kernel, it may include references to user processes, and, if "ustack()"
is used, then dtrace will examine the running process to get the
loaded libraries and walk the stack.
In theory, dtrace should handle this (mostly via the ELF libraries),
but, dtrace assumes a Solaris style /proc filesystem, and not the Linux
one. (The Linux port attemps to get this "right" but its not fully proven).
I will look at what/where the "gotchas" are. Would be nice to not
worry about the binary type.
Post created by CRiSP v10.0.3a-b5931
No comments:
Post a Comment