pr4225 branch status

[Jim Keniston]

On Sun, 2008-08-03 at 10:18 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> The git repo now contains a copy of my pr4225 working branch.  It has
> made some progress recently.  On a kernel with working utrace+uprobes
> (which at the moment is only rhel5 I believe), probes like this kind
> of work, if you have the debugging information installed:
> 
>    probe process("/bin/ls").function("*") { log(probefunc()) }
> 
> It's very raw, so think of it only as a new way of testing the uprobes
> module.

I played with Frank's new stap on an i686 system using an old version of
utrace (with kernel.org 2.6.24) and uprobes.ko built in the kernel tree.
(Uprobes doesn't yet work with the new utrace.)

Some stuff worked, some didn't.  See below.

> I'm working on fixing a (diagnosable, user-context-level)
> hang for processes that fork, so don't probe forky shells yet!

I think that the above is a uprobes bug.  Uprobes seems to handle fork()
OK, but the version of clone() that bash uses doesn't look like fork()
or vfork(), as far as I can tell.

> 
> There are also some temporary functional regressions
> (symbol-table-only probing and some other minor stuff) that I believe
> also need fixing before merging this into mainline.
> 
> - FChE

In the report below, "works" means it seemed to work for me, and
"doesn't work" means I couldn't get it to work.

(+) probe process(PATH).function(FUNC) works in general.
(-) probe process(PID).function(FUNC) doen't work (syntax error).
(+) probe process(PATH).function("*") works.
(-) probe process(PATH).function("*@file.c") doesn't work.
(+) Despite Frank's warning above, starting or ending a script session
while the probed process runs seems to work just fine, and so does
starting or terminating one or more probed processes while the script
runs.
(+) It works on C++ programs.  probefunc() doesn't include the
"classname::" prefix.
(+) Return probes work.
(+) $return works in return probes.
(-+) On x86-32, target vars ($var), including function args, don't work
until you apply the enclosed patch.
(-) Probing stap and staprun doesn't work.  I get messages like
"semantic error: missing relocation base against: identifier 'process'
at stap.stp:1:7".  This may be related to the fact that the file(1)
command thinks stap and staprun are shared objects.
(-) Dwarfless user-space probing hasn't been implemented yet.  (That's
on my list.)
(+) ... but <type>_arg(n) functions work.  (This is probably NOT yet
true of powerpc.)
(x) As far as I can tell, the PATH in process(PATH) needs to
match /proc/<pid>/exe.  If PATH includes a symbolic link, it won't work.

Keep up the good work!

Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dwarf_reg4_i386.patch
Type: text/x-patch
Size: 1174 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20080804/0958a4f5/attachment.bin>