This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/15999] New: symbol-table-based fallback for foo.function() should resolve $$vars etc.
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 04 Oct 2013 15:41:43 +0000
- Subject: [Bug translator/15999] New: symbol-table-based fallback for foo.function() should resolve $$vars etc.
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=15999
Bug ID: 15999
Summary: symbol-table-based fallback for foo.function() should
resolve $$vars etc.
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: fche at redhat dot com
While running
% stap -p2 -v para-callgraph-verbose.stp
'process("/usr/lib64/libpcp_pmda.so.*").function("*")'
found something odd with git stap vs. old systemtap. Scripts
like para-callgraph-verbose* use $$parms$$, expecting that
absent or inaccessible $vars will be represented at least by
nothing, but that the script as a whole will run.
This does not seem to be working any more, with the symbol-table
(minidebuginfo) type fallback to dwarf. Not for example the
_init function:
./stap -v -p2 -e 'probe
process("/usr/lib64/libpcp_pmda.so*").function("_init").call {
println($$parms$$) }'
Pass 1: parsed user script and 107 library script(s) using
218684virt/36724res/2784shr/34060data kb, in 400usr/40sys/640real ms.
semantic error: unresolved target-symbol expression: identifier '$$parms$$' at
<input>:1:78
source: probe
process("/usr/lib64/libpcp_pmda.so*").function("_init").call {
println($$parms$$) }
^
In previous versions of stap, the probe point itself would not
be accessible. Now we get them, but don't expand all the
$$vars etc. to at least empty strings.
--
You are receiving this mail because:
You are the assignee for the bug.