Re: lots of systemtap language questions

Re: lots of systemtap language questions

[Frank Ch. Eigler]

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

Re: lots of systemtap language questions

[Martin Hunt]

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

Re: lots of systemtap language questions

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Hi -

hunt wrote:

> [...]
> > > 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()?

Good.

> [...]
> stack() - should be backtrace()?

Yeah.

> print_regs() - register dump

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

Yes, good idea.

> I've also done print(), which is like log() except uses _stp_print() [...]

OK.

It would be great to have a few lines of documentation in the
stapfuncs.5 man page for each of these functions, and a buildok test
to verify that script code using them compiles.


> > 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.

On a 64-bit host, the default MAXSTRINGLEN could increase.

> (Due to the lack of a frame pointer, that's all we can do right
> now.)

When we start supporting user-level code, we may have to bite the
bullet and support real stack frame unwinding, perhaps by transcribing
the dwarf unwind data into the probe program.  Or we may have to
propagate the hack to user space.  We certainly won't be able to
require people to stop using -fomit-frame-pointers.


> I'll have to implement a special function to turn those addresses
> into a stack trace at probe exit. [...]

How do you envision this working?  stpd post-processing trace data?
"probe end {}" script code calling this special function?


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: how to remove shellsnoop?

[Martin Hunt]

On Fri, 2005-09-02 at 13:55 +0800, CHANG Xiaolin wrote:
> Hi,
> I "insmod runtime/probes/shellsnoop/shellsnoop.ko".

That is a bad idea, but it should be harmless.

> There is no error.
> But when I "rmmod shellsnoop", the computer restarts.
> 
> Could anyone explain the reason? We  can not use rmmod to remove
> shellsnoop modules? if not, how to remove shellsnoop module ?

I tried this on several different OSes and cpus and it never happened to
me, so I cannot guess what is going on.

The only supported way to load modules built using the systemtap runtime
is with stpd.  From the systemtap directory, it would be
"../../stpd/stpd shellsnoop.ko"  Or install stpd in your path and you
can just do "stpd shellsnoop.ko"

Martin