This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: lots of systemtap language questions
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 31 Aug 2005 21:03:29 -0400
- Subject: Re: lots of systemtap language questions
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.)
(By the way, "$current" does not exist as such: on 386, it's a macro
that expands to an inline function.)
> 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).
> For things like printing registers or stack, how should it work?
> I have this working:
>
> probe kernel.function("uptime_read_proc") {
> log("Now in uptime")
> print_regs()
> print_stack()
> log("the stack is " . stack())
> }
>
> So you can print the registers or stack directly or get them in a string
> and then print them. The latter doesn't really work well because
> MAXSTRINGLEN is 128, which makes for short stack traces.
OK.
> 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. With the current MAXSTRINGLEN value, that
should be enough for a dozen levels. With a tighter encoding or
longer strings, more.
Another function would take such a string, and return a symbolic form
corresponding to one frame level from that string. Another function
(a newer form of your "print_stack") could take that string, and
implicitly iterate & log each symbolic form.
- FChE