Re: lots of systemtap language questions

["Frank Ch. Eigler" <fche at redhat dot com>]

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: pgp00000.pgp
Description: PGP signature