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: variables in scopes


Ulrich Drepper wrote:

Vara Prasad wrote:
....


I'm talking about either inlined functions or code like this:

int foo (int a, int b) {
 int c = a;
 if (c != 0) {
   int a = 42 + b;
   bar(&a);
   c += a;
 }
 return c;
}

Here 'a' is shadowed. You can easily construct a similar case with
inlining. And both variables could be parameters, of local variables,
or any combination.


O.K, now i understand what you mean by shadow variables and it makes sense.

In DWARF the if block is encoded with DW_TAG_lexical_block.  This is one
level down from the block of the function.  So the variable could
theoretically be accessed for a probe at the call to 'bar' with

@a@

and the parameter with

@a\1@

meaning, one level up.



I still prefer function syntax to access these variables than language constructs.



Can you give me some example usage for this feature in a systemtap script?



I think you see that the misunderstanding has prevented you from seeing an application. A probe at the call to 'bar' certainly might want to look at the parameter 'a'.



I still go back to my original point that we should let probe handler have access to only the local variables that it will have access if the handler was written inline in the function being probed. In this case since inline code will not have access to parameter "a" i am thinking probe handler should not have, may be original author had a good reason why it was shadowed.


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