Re: lots of systemtap language questions

[Martin Hunt <hunt at redhat dot com>]

On Wed, 2005-08-31 at 21:03 -0400, Frank Ch. Eigler wrote:
> hunt wrote:
> 
> > [...]
> > If we are going to have builtin variables, how to do it?  For example
> > "pid" which would be simply $current->pid (when not in interrupts)? Can
> > we make this a variable or do we make it a function, which is easy?
> 
> For now, let's skip "builtin variables" as such, and live with
> functions that return the values.  Even these functions are not
> "builtins", but ones just pulled in from the script library.  (The
> current files named src/tapset/builtin_* may get just renamed at some
> point.)

I called them builtins because are core functions and we have the
builtin_ tapsets. Maybe three of us care how we implement them.

> > Whichever we pick, should the basic builtins have some common prefix?
> > Or we just have pid(), caller(), pid(), ppid(), gid(), stack(), etc?
>
> I suggest going for simple names for the obvious ones ("caller" and
> "stack" are not quite as obvious as the others).

Hmm.  How about calling_function(), calling_address() and backtrace()?

So far I have done 
pid()
ppid()
execname() - name of the executable, current->comm
pexecname() - name of the parent executable, current->parent->comm
uid()
euid()
gid()
egid()
stack() - should be backtrace()?
print_regs() - register dump

Maybe I should call everything that prints directly print_xxx()?  The
rest of the functions return ints or strings.

I've also done print(), which is like log() except uses _stp_print() so
it is more efficient. Not sure what should really be done there. log()
always sends an immediate message, bypassing any buffering. It's good
for debugging, especially when using relayfs, but maybe not much else.


> > Also, I need to add some arguments to the stack functions to
> > indicate the stack level to do and if symbolic lookups should be
> > done. Any syntax preferences for this?
> 
> Recall another option we talked about: stack() (or whatever it ends up
> being named) returns a string with all the relevant PCs in hex, but
> with no symbolic decoding.  

That's what you currently get if you don't tell it to do symbolic
lookups.  It's always done that.

> With the current MAXSTRINGLEN value, that
> should be enough for a dozen levels.  

Seven levels on 64-bit archs and you lose at least 2 or 3 of those due 
to duplicate info because our backtraces are really only dumps of
addresses on the stack that appear to be function addresses. (Due to the
lack of a frame pointer, that's all we can do right now.)

I'll have to implement a special function to turn those addresses into a
stack trace at probe exit.  I wanted to tag stuff like this so it could
happen automatically to any trace info in the buffer, but for now we'll
have to save it it an array and explicitly convert it to a stack trace.

Martin