This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/10799] New: global vs local variable confusion
- From: "mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 17 Oct 2009 11:22:59 -0000
- Subject: [Bug translator/10799] New: global vs local variable confusion
- Reply-to: sourceware-bugzilla at sourceware dot org
Here is a stap puzzler:
Why does the output of these scripts differ so much:
$ stap -e 'global syscalls=0; probe syscall.* { syscalls++ } probe end {
printf("syscalls: %d\n", syscalls) }' -c 'sleep 5'
syscalls: 22492
$ stap -e 'global count=0; probe syscall.* { count++ } probe end {
printf("syscalls: %d\n", count) }' -c 'sleep 5'
syscalls: 5
Note that while in the first the number of syscalls fluctuates somewhat
depending on what is being run, in the second count is always constantly 5.
Looking at the generated source code we see that for the first variant we see
two probe_ functions. One that hooks each syscall kernel.function, and one for
the end probe. But for the second there are more...
In the second case each syscall probe alias that defines a local variable
'count' generates a new probe_ function body. In such a function body we see
something curious:
{
(void)
({
l->__tmp0 =
({
function__dwarf_tvar_get_count_1410 (c);
if (unlikely(c->last_error)) goto out;
c->locals[c->nesting+1].function__dwarf_tvar_get_count_1410.__retvalue;
});
global.s_count = l->__tmp0;
l->__tmp0;
});
(void)
({
l->__tmp3 = global.s_count;
global.s_count += 1;
l->__tmp3;
});
}
Not only is the local dwarf count variable retrieved, but global.s_count is
first assigned that value before 1 is added to it. Whoa!
--
Summary: global vs local variable confusion
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: mjw at redhat dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=10799
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.