Re: full dwarf backtracing kernel to user

[Mark Wielaard <mjw at redhat dot com>]

On Mon, 2011-07-11 at 13:35 +0200, Mark Wielaard wrote:
> There is one function, task_backtrace() function, which given a pointer
> (long) to a task struct produces a hex backtrace of an arbitrary task,
> that I am unsure about. Because it doesn't really fit with the rest of
> the backtrace functions, which all act on the current probe context.
> Sadly this function is not marked EXPERIMENTAL and people might already
> rely on it.

We discussed it on irc and agreed it could be deprecated because nothing
really uses it (except one very small example dumpstack.stp that
basically does nothing else than just call this function).

I have to admit I didn't know we had a deprecation mechanism, so if you
also didn't know how to do this, then look at the attached patch (it is
really easy!). Now if you run stap with --check-version and you use a
deprecated function like this it will say:

WARNING: This function uses tapset constructs that are dependent on
systemtap version: identifier 'task_backtrace'
at /usr/local/install/systemtap/share/systemtap/tapset/context-unwind.stp:91:10

After 1.6 is released I'll remove this.

> There is also print_stack(), also not marked EXPERIMENTAL, which really
> does the same as sprint_stack(), turning a hex string list into a symbol
> resolved kernel backtrace. They just differ slightly in how they print
> out stuff.

I didn't deprecate this one because it isn't such a big deal to keep
supporting it. But we could if people think it would make the provided
tapsets more consistent.

> There is also the print_ubacktrace_brief () function, which does print
> things slightly differently from normal, and surprisingly doesn't have
> any sprint counterpart, so cannot be used in tapsets splitting
> ubacktrace collecting (space separated hex string list) and then
> printing (using the sprint functions).

Likewise kept for now.

> A lot of code actually deals with the various formats. I am unsure if we
> really want to maintain that. Opinions?

Cheers,

Mark

commit 20ab10df946293a9b9d403c6ac17f9b6a4351f0d
Author: Mark Wielaard <mjw@redhat.com>
Date:   Fri Jul 22 17:46:10 2011 +0200

    Deprecated task_backtrace:string (task:long).
    
    This function will go away after 1.6.

diff --git a/NEWS b/NEWS
index 4122692..35bc4c9 100644
--- a/NEWS
+++ b/NEWS
@@ -41,6 +41,9 @@
 
 - Depends on elfutils 0.142+.
 
+- Deprecated task_backtrace:string (task:long). This function will go
+  away after 1.6. Please run your scripts with stap --check-version.
+
 * What's new in version 1.5, 2011-05-23
 
 - The compile server and its related tools (stap-gen-ert, stap-authorize-cert,
diff --git a/tapset/context-unwind.stp b/tapset/context-unwind.stp
index 0b42201..656e01c 100644
--- a/tapset/context-unwind.stp
+++ b/tapset/context-unwind.stp
@@ -87,11 +87,13 @@ function backtrace:string () %{ /* pure */
  *  that are a backtrace of the stack of a particular task
  *  Output may be truncated as per maximum string length.
  */
+%( systemtap_v <= "1.6" %?
 function task_backtrace:string (task:long) %{ /* pure */
         _stp_stack_snprint_tsk(THIS->__retvalue, MAXSTRINGLEN,
                                (struct task_struct *)(unsigned long)THIS->task,
                                _STP_SYM_NONE, MAXTRACE);
 %}
+%: %)
 
 /**
  *  sfunction caller - Return name and address of calling function