Re: access pointer and global variables

["Stone, Joshua I" <joshua dot i dot stone at intel dot com>]

David Smith wrote:
> Hmm.  What you are asking for is this:
>
> probe kernel.function("schedule") {
>     printf("pid is %d\n", $prev->pid)
>     prev_copy = $prev
>     printf("pid is still %d\n", prev_copy->pid)
> }
>
> That is going to be tricky to implement.

That's not really what I meant.  If you figure out how to do that, 
awesome, but that certainly adds a lot of complication to SystemTap types.

Let me try to rephrase.  In an entry probe, we see $prev->pid and we 
know how to generate code to dereference it.  When we're generating code 
for the return probe, wouldn't you still know what the type looked like? 
 I suppose it depends on how you generate that code.  But when I see this:

    probe kernel.function("schedule").return {
        printf("pid is %d\n", $prev->pid)
    }

I expect that the translator could produce one of these options:

    probe kernel.function("schedule") {
        cache[...] = $prev
    }
    probe kernel.function("schedule").return {
        printf("pid is %d\n", cache[...]->pid)
        // The dereference happens using the same loc2c
        // generated function that the entry would have used.
    }

OR

    probe kernel.function("schedule") {
        cache[...] = $prev->pid
    }
    probe kernel.function("schedule").return {
        printf("pid is %d\n", cache[...])
    }

The former works if you're immediately generating code, so you don't 
have to remember the extra type information for long.  But I expect the 
latter should be a lot easier to do, at the expense of more caching 
memory if many fields are dereferenced.

> David "Grumble - dang users never satisfied.  Give them parameters in 
> return probes, and they are happy for a moment.  Then they want more, 
> always more.  I can remember when we only had toggle switches on the 
> front of the vax and were happy to have them..." Smith

I only ask because you're so good about providing. :)


Josh