This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [kprobe bug] pre-handler changes on globals lost


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]