CRiSP Newsletter
Testimonials
| Dtrace - 32bit apps on 64bit kernels |
|
|
|
|
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 Read more http://crtags.blogspot.com/2011/01/dtrace-32bit-apps-on-64bit-kernels.html |




