Re: pr4225 branch status

[Jim Keniston <jkenisto at us dot ibm dot com>]

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

Enhance x86_32 dwarf_register_4 to work with uprobes, so $target vars work.

--- old/runtime/loc2c-runtime.h	2008-08-04 12:56:08.000000000 -0700
+++ new/runtime/loc2c-runtime.h	2008-08-04 12:55:37.000000000 -0700
@@ -113,16 +113,13 @@
    kernel mode, it is not saved in the trap frame (struct pt_regs).
    The `esp' (and `xss') fields are valid only for a user-mode trap.
    For a kernel mode trap, the interrupted state's esp is actually an
-   address inside where the `struct pt_regs' on the kernel trap stack points.
-
-   For now we assume all traps are from kprobes in kernel-mode code.
-   For extra paranoia, could do BUG_ON((regs->xcs & 3) == 3).  */
+   address inside where the `struct pt_regs' on the kernel trap stack points. */
 
 #define dwarf_register_0(regs)	regs->eax
 #define dwarf_register_1(regs)	regs->ecx
 #define dwarf_register_2(regs)	regs->edx
 #define dwarf_register_3(regs)	regs->ebx
-#define dwarf_register_4(regs)	((long) &regs->esp)
+#define dwarf_register_4(regs)	(user_mode(regs) ? regs->esp : (long)&regs->esp)
 #define dwarf_register_5(regs)	regs->ebp
 #define dwarf_register_6(regs)	regs->esi
 #define dwarf_register_7(regs)	regs->edi