Syscalls and Unwinding

It’s been a bit. Been very busy with assorted Frysk related deadlines. Things have let up, and I’ve a little more time to write.

There’s some excellent work that has been done – and is continuing – on stack-trace unwinding. It’s an integral piece of any debugger/execution analysis suite. I posted on the Frysk external list recently in reply to this work some speculation on the ability to capture a stack-trace on a system-call (or filtered system-calls).

If we do this, when we log that the system-call has been entered in a monitored thread, we can render a click-able link in the log that will take you to the point in the code the system-call happened. This has all sorts of costs associated with it, so the idea very much blue-sky. But it would be nice to click on a list of sys-calls and find out where in the symbol-enabled code each one originated from.

I’ve also been sucked into some Java-GNOME bindings issues. In FC6 some glibc pointer warnings crop up with the bindings. Tracking these down are very difficult, not only because debugging native code in Java can be very tricky in the most vanilla of situations, but the native blobs are processed for free’ing during a g_idle loop. So not only is there the Java GC() scheduling to deal with, but also the idle-loop reaps the native objects at n time in the future. It’s a very challenging debugging scenario, and I cannot but smile at the apparent schadenfreude that fate takes, considering the project I work on.

Work in the horizon includes disassembly, fixing the marshalling widget to record per thread events for the event-viewer (ie fork, syscall, clone and so on), and a mixed bag of other tasks. There’s been a good amount of work on system-calls, and Tom Tromey seems to be having a tremendous amount of fun hacking on ftrace. So happy hacking!

Post a comment

Copyright © Phil Muldoon

Built on Notes Blog Core
Powered by WordPress