[PR6580; patch for review] incremental unwind enhancement

[Serguei Makarov]

Updated version of the backtrace/unwind patch based on feedback. This one makes the cache *optional* (enabled with -DSTP_FULL_BACKTRACE_CACHE); otherwise, only the current unwind state for each of user / kernel space is retained, which is sufficient to implement PR6580 tapset functions efficiently so long as they call stack() / ustack() with increasing consecutive numbers.

Added initialization overhead for a probe prologue is now only two assignments (to set depth = 0 on both unwind states). This is probably tolerable; I could modify one of the visitors to search for /* pragma:unwind */ in tapset functions used by a probe and generate the code conditionally, but that would be severe overkill.

The patch is robust enough to pass the exelib.exp stress test, among other things. Any feedback/nitpicking would be very welcome, though.

----- Original Message -----
From: "Serguei Makarov" <smakarov@redhat.com>
To: systemtap@sourceware.org
Cc: "Frank Ch. Eigler" <fche@redhat.com>, "Mark Wielaard" <mjw@redhat.com>
Sent: Wednesday, September 5, 2012 11:43:07 AM
Subject: [PR6580; patch for review] first step of unwind_cache enhancement

The first incremental step to the runtime tweaks required to sanely implement PR6580. Namely, the kernel-side backtrace can be unwound one step at a time using _stp_stack_kernel_get, with the already unwound portion of the backtrace cached within the probe context.

This allows us to implement stack(n) (which returns the PC n levels deep within the stack) without having to resort to tokenizing a backtrace string each time.

The patch itself seems to be sound, but testing it drew attention to memory corruption errors in the existing DWARF unwinder (see PR14546).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uwcache.patch
Type: text/x-patch
Size: 21052 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20120913/3a898109/attachment.bin>