| Summary: | Dyninst does not support probefunc() | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Sami Wagiaalla <swagiaal> |
| Component: | dyninst | Assignee: | Unassigned <systemtap> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bugzilla, jistone, scox |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Bug Depends on: | 14703 | ||
| Bug Blocks: | |||
I suspect this is essentially bug #16795. (In reply to Philip Withnall from comment #1) > I suspect this is essentially bug #16795. Er, I meant bug #14703. Copy–paste error, sorry. (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. |
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