Bug 15586 - Dyninst does not support probefunc()
Summary: Dyninst does not support probefunc()
Status: RESOLVED DUPLICATE of bug 14703
Alias: None
Product: systemtap
Classification: Unclassified
Component: dyninst (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on: 14703
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-05 18:58 UTC by Sami Wagiaalla
Modified: 2020-06-16 21:12 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sami Wagiaalla 2013-06-05 18:58:51 UTC
running something like:

stap --runtime=dyninst  -c './example' -e 'probe process.function("bar").call{log(probefunc())}'
semantic error: unresolved arity-0 function: identifier 'probefunc' at <input>:1:40
        source: probe process.function("bar").call{log(probefunc())}
                                                       ^

Pass 2: analysis failed.  [man error::pass2]

This of course works:
stap  -c './example' -e 'probe process.function("bar").call{log(probefunc())}'
bar
Comment 1 Philip Withnall 2016-08-18 15:52:50 UTC
I suspect this is essentially bug #16795.
Comment 2 Philip Withnall 2016-08-18 15:53:57 UTC
(In reply to Philip Withnall from comment #1)
> I suspect this is essentially bug #16795.

Er, I meant bug #14703. Copy–paste error, sorry.
Comment 3 Josh Stone 2016-08-18 16:06:15 UTC
(In reply to Philip Withnall from comment #2)
> Er, I meant bug #14703. Copy–paste error, sorry.

Yeah, probefunc() dynamically maps the IP to symbols.  That's more generally useful for probes which aren't tied to specific code locations, like timers.

You should be able to use ppfunc() though, which pulls the function name out of the probe's own location string.
Comment 4 Stan Cox 2020-06-16 21:12:32 UTC
"The dyninst runtime currently lacks any symbol resolution or backtrace functions."

*** This bug has been marked as a duplicate of bug 14703 ***