Re: pr4225 branch status

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

Hi -

On Mon, Aug 04, 2008 at 02:56:37PM -0700, Jim Keniston wrote:
> [...]
> Some stuff worked, some didn't.  See below.

Thanks for testing!

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

(Do you need a bug report for this?)


> [...]
> (-) probe process(PID).function(FUNC) doen't work (syntax error).

This would be tricky, as based on a PID only, at translation time we
don't know which ELF file to search.  (Think cross-compliation.)

> [...]
> (-) probe process(PATH).function("*@file.c") doesn't work.

It works for me, but "file.c" must be identically adorned (with
respect to full or partial path names) as in the dwarf file.  A good
case could be made for tweaking filename matching to implicitly be
prefixed with "**/" - so any prefix directory would also match.
See also PR5049.  Any opinions?


> [...]
> (+) It works on C++ programs.  probefunc() doesn't include the
> "classname::" prefix.

Demangling ... should we do it in the runtime on demand, or in the
compiled-in data, or not at all?


> (-+) On x86-32, target vars ($var), including function args, don't work
> until you apply the enclosed patch.

(Make it so!)


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

It's because they're compiled -fpie, i.e., are relocatable as are
shared objects.  Those will need the task-finder's vm-callback logic
rather then plain process begin-end callbacks.  Coming soon.


> (-) Dwarfless user-space probing hasn't been implemented yet.  (That's
> on my list.)

I must unbreak kernel-side dwarfless stuff too.

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

The translator needs to canonicalize process(PATH), including via $PATH
searching.


- FChE