Bug 5049 - Support relative and absolute pathnames in probe PATTERNs
Summary: Support relative and absolute pathnames in probe PATTERNs
Alias: None
Product: systemtap
Classification: Unclassified
Component: documentation (show other bugs)
Version: unspecified
: P3 minor
Target Milestone: ---
Assignee: Frank Ch. Eigler
: 4397 (view as bug list)
Depends on:
Reported: 2007-09-19 21:44 UTC by Jim Keniston
Modified: 2008-09-23 02:53 UTC (History)
0 users

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Jim Keniston 2007-09-19 21:44:02 UTC
A user was having trouble getting stap to accept a statement"func@file:line")
probe.  The fix was to change the "file" component from an absolute pathname to
a pathname relative to the root of the kernel source tree.

Neither the stapprobes man page nor the Language Reference make it clear that
the pathname must be relative, although the examples in the Language Reference
show relative pathnames.

Am I correct in thinking that the pathname must be relative?  Does this need to
be clarified anywhere besides in the stapprobes man page and the Language Reference?
Comment 1 Frank Ch. Eigler 2007-09-20 00:38:50 UTC
> Am I correct in thinking that the pathname must be relative?

Not exactly.  The path name patterns need to match the path names as
seen by the compiler.  A Red Hat kernel build happens to use relative
names, but others may not.  We should try harder to support both, perhaps
with an implicit "**"-equivalent widget at the front of the path name
Comment 2 Frank Ch. Eigler 2007-10-15 19:44:27 UTC
*** Bug 4397 has been marked as a duplicate of this bug. ***
Comment 3 Frank Ch. Eigler 2008-08-11 17:26:58 UTC
Please check the effect of commit #2ed8949.
Comment 4 Frank Ch. Eigler 2008-08-11 19:25:25 UTC
Not quite so easy ... we wouldn't want
to match

So the implicit "*" in the front should only refer to what in
regexp language would be written (.*/)?
Comment 5 Frank Ch. Eigler 2008-08-11 20:18:47 UTC
ah, commit 79640c2 may be good enough.
Comment 6 Frank Ch. Eigler 2008-09-23 02:53:05 UTC