This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: [kprobe bug] pre-handler changes on globals lost
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Rusty Lynch <rusty dot lynch at intel dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 16 Jun 2005 12:32:00 -0400
- Subject: Re: [kprobe bug] pre-handler changes on globals lost
- References: <200506152333.j5FNX2uH031340@linux.jf.intel.com>
> While working with some kprobe unit test, I stumbled across some wacky
> behavior that the below module exposes.
> [...]
I think I figured this out. From the assembly code for x86:
Compare and contrast this:
static int show_run_tc1(char *page, char **start, off_t offset,
int count, int *eof, void *data)
{
int initial = pcount;
if (target1() != (initial + 1))
return -EINVAL;
return 0;
}
show_run_tc1:
pushl %ebx
movl pcount, %ebx
call target1
movl %eax, %edx
incl %ebx
movl $-22, %eax
... with:
static int show_run_tc2(char *page, char **start, off_t offset,
int count, int *eof, void *data)
{
int initial = pcount;
if (target2() != (initial + 1))
return -EINVAL;
return 0;
}
show_run_tc2:
call target2
movl pcount, %edx
movl %eax, %ecx
movl $-22, %eax
incl %edx
See it? In the second case, the compiler copies pcount to %edx after
the call to target2; in the first case, it does it *before* the call
to target1. It probably guesses it can do that because, seeing into
target1, it knows that the global is not modified there.
I don't think this compiler optimization will have any impact on
systemtap, since we won't be setting breakpoints on code right within
the generated module, where "invisible" changes would be made to
globals.
- FChE