This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: architecture paper draft


Hi -


> [...]
> Symbolic names are more useful. However, just using the argument name of
> the original function could have name collisions with some global variable,
> so there probably still needs to be some means of distinguishing between
> argument and global scope variable.

In other words, we need to reinvent scoping rules for
accessing context-side variables (and types).  It may
be acceptable to have a range of syntax such as

	context.var	// look up "var" using usual C scoping rules
	source("driver/file.c").var // look for global vars in .c file

> [...]
> >Another interesting angle is to think about how to generalize this
> >mechanism to provide some run-time extensibility for systemtap, so
> >that such a probe-specification namespace might be populated at
> >startup time from a library of scripts.  [...]
> 
> I was expecting that some of this code would be in a runtime library 
> because the addresses of the operations would not be known when the 
> instrumentation script is compiled. [...]

No, I meant something stronger than that.  (Certainly, none of the
addresses are reliably known when the script is *compiled*!)  What
I meant was the possibility of a script developer expert to put
fragments like

	probe foo.bar = object("foo.ko").address("function") +
	     [[ module_find("foo") ]];

into the script library.  Yeah, the syntax is imaginary, but
tries to express that the foo.bar probe point address is to
be computed at module_init time using arithmetic as given.
The object().address() would map to an ELF symbol table lookup,
which could be done at translation time.  The "[[" / "]]" brackets
could enclose raw C to be copied straight into the module, in its
initialization code, sort of like yacc semantic actions.

Do you see what sort of generality I'm imagining?  No additional
systemtap library runtime; little hard-coded in the tool except
for expansions of basic primitives like object().address().


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]