This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: pr4225 branch status
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