* [Bug translator/11769] New: process.mark probes losing arguments
@ 2010-06-30 19:09 dsmith at redhat dot com
2010-06-30 23:55 ` [Bug translator/11769] " jistone at redhat dot com
0 siblings, 1 reply; 2+ messages in thread
From: dsmith at redhat dot com @ 2010-06-30 19:09 UTC (permalink / raw)
To: systemtap
On s390x (kernel 2.6.18-194.el5), the testsuite/semok/thirtysix.stp test fails:
# stap -vp3 ../src/testsuite/semok/thirtysix.stp
Pass 1: parsed user script and 71 library script(s) using
29468virt/20976res/2608shr kb, in 190usr/10sys/208real ms.
semantic error: unable to find local 'nosuchvar' near pc 0x8010035a in
<unknown>(../src/cache.cxx) (alternatives: $arg1 $arg2): identifier '$nosuchvar'
at ../src/testsuite/semok/thirtysix.stp:14:66
source: probe process("stap").mark("*")? {
println(@defined($arg1)?$arg1:$nosuchvar) } # valid
^
Pass 2: analyzed script: 228 probe(s), 25 function(s), 5 embed(s), 3 global(s)
using 106160virt/52596res/4852shr kb, in 620usr/120sys/745real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
OK, so the failing line is the following:
probe process("stap").mark("*")? { println(@defined($arg1)?$arg1:$nosuchvar) }
The test is trying to make sure @defined() is working properly. The above test
can be simplified by removing @defined():
# stap -vp4 -e 'probe process("stap").mark("*") { println($arg1) }'
Pass 1: parsed user script and 71 library script(s) using
29368virt/20888res/2608shr kb, in 190usr/10sys/205real ms.
semantic error: not accessible at this address (0x8010035a): identifier '$arg1'
at <input>:1:43
source: probe process("stap").mark("*") { println($arg1) }
^
Pass 2: analyzed script: 19 probe(s), 16 function(s), 0 embed(s), 0 global(s)
using 43436virt/24164res/4088shr kb, in 60usr/0sys/60real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
OK, let's look at all the mark probes and see if $arg1 exists:
# stap -L 'process("stap").mark("*")'
process("stap").mark("cache__add__module")
process("stap").mark("cache__add__source")
process("stap").mark("cache__clean") $arg1:char const* volatile
process("stap").mark("cache__get")
process("stap").mark("pass0__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass0__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1a__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass1b__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass2__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass2__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass3__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass3__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass4__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass4__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass5__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass5__start") $arg1:struct systemtap_session* volatile
process("stap").mark("pass6__end") $arg1:struct systemtap_session* volatile
process("stap").mark("pass6__start") $arg1:struct systemtap_session* volatile
That's odd output, since in the source the markers without arguments do have
arguments:
STAP_PROBE2(stap, cache__add__module, module_src_path.c_str(), s.hash_path.c_\
str());
STAP_PROBE2(stap, cache__get, c_src_path.c_str(), s.hash_path.c\
_str());
STAP_PROBE2(stap, cache__add__source, s.translated_source.c_str(), c_dest_pat\
h.c_str());
I'm unsure if the fact that all the failing markers have 2 arguments is significant.
Here's a test of a single failing marker:
# stap -vp4 -e 'probe process("stap").mark("cache__get") { println($arg1) }'
Pass 1: parsed user script and 71 library script(s) using
29368virt/20888res/2608shr kb, in 190usr/10sys/209real ms.
semantic error: not accessible at this address (0x8010035a): identifier '$arg1'
at <input>:1:52
source: probe process("stap").mark("cache__get") { println($arg1) }
^
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 43048virt/23512res/3788shr kb, in 10usr/0sys/14real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
On f13 x86 and rhel6 x86_64, the problem is actually worse - none of the markers
have arguments:
# stap -L 'process("stap").mark("*")'
process("stap").mark("cache__add__module")
process("stap").mark("cache__add__source")
process("stap").mark("cache__clean")
process("stap").mark("cache__get")
process("stap").mark("client__end")
process("stap").mark("client__start")
process("stap").mark("pass0__end")
process("stap").mark("pass0__start")
process("stap").mark("pass1__end")
process("stap").mark("pass1a__start")
process("stap").mark("pass1b__start")
process("stap").mark("pass2__end")
process("stap").mark("pass2__start")
process("stap").mark("pass3__end")
process("stap").mark("pass3__start")
process("stap").mark("pass4__end")
process("stap").mark("pass4__start")
process("stap").mark("pass5__end")
process("stap").mark("pass5__start")
process("stap").mark("pass6__end")
process("stap").mark("pass6__start")
process("stap").mark("stap_system__complete")
process("stap").mark("stap_system__spawn")
process("stap").mark("stap_system__start")
--
Summary: process.mark probes losing arguments
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: dsmith at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=11769
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug translator/11769] process.mark probes losing arguments
2010-06-30 19:09 [Bug translator/11769] New: " dsmith at redhat dot com
@ 2010-06-30 23:55 ` jistone at redhat dot com
0 siblings, 0 replies; 2+ messages in thread
From: jistone at redhat dot com @ 2010-06-30 23:55 UTC (permalink / raw)
To: systemtap
------- Additional Comments From jistone at redhat dot com 2010-06-30 16:33 -------
(In reply to comment #0)
> On f13 x86 and rhel6 x86_64, the problem is actually worse - none of the markers
> have arguments:
>
> # stap -L 'process("stap").mark("*")'
> process("stap").mark("cache__add__module")
I think this is just a problem in listing_mode -- a script which accesses $arg1
on this probe still works fine. We list args using derived_probe::getargs(),
but the uprobe_derived_probe doesn't know about the SDT debuginfoless args.
This is only for x86, so we should treat it separately from this s390 issue.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11769
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-09-14 17:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-11769-6586@http.sourceware.org/bugzilla/>
2011-09-14 17:48 ` [Bug translator/11769] process.mark probes losing arguments fche at redhat dot com
2010-06-30 19:09 [Bug translator/11769] New: " dsmith at redhat dot com
2010-06-30 23:55 ` [Bug translator/11769] " jistone at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).