Does This Probe Make Sense?

Does This Probe Make Sense?

[Dave Brolley]

I ran across this while writing the unprivileged_all.exp test suite last 
week.  I was unable to create an example for which a probe of the form:

     process.function(ADDRESS).inline

would resolve. It was suggested by fche that this probe didn't make much 
sense to him in the first place. I would like to arrive at a definitive 
answer. Does this probe make any sense and, if so, can someone provide 
an example?

Thanks,
Dave

Re: Does This Probe Make Sense?

[Josh Stone]

On 08/30/2011 08:37 AM, Dave Brolley wrote:
> I ran across this while writing the unprivileged_all.exp test suite last 
> week.  I was unable to create an example for which a probe of the form:
> 
>      process.function(ADDRESS).inline
> 
> would resolve. It was suggested by fche that this probe didn't make much 
> sense to him in the first place. I would like to arrive at a definitive 
> answer. Does this probe make any sense and, if so, can someone provide 
> an example?

Hmm, I found one:

> $ stap -l 'process("stap").function("main")'
> process("/usr/local/bin/stap").function("main@../main.cxx:935")
> $ stap -l 'process("stap").function("main")' -vv |& grep pc=
> probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> $ stap -l 'process("stap").function(0x40d510).*'
> process("/usr/local/bin/stap").function(0x40d510).call
> process("/usr/local/bin/stap").function(0x40d510).return
> $ stap -l 'process("stap").function(0x40d510).*' -vv |& grep pc=
> probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> $ stap -l 'process("stap").function(0x40d610).*'
> process("/usr/local/bin/stap").function(0x40d610).inline
> $ stap -l 'process("stap").function(0x40d610).*' -vv |& grep pc=
> probe size@/usr/lib/gcc/x86_64-redhat-linux/4.6.0/../../../../include/c++/4.6.0/bits/stl_vector.h:570 process=/usr/local/bin/stap reloc=.absolute pc=0x40d5fd

But I don't like that behavior, especially since the last one doesn't
have any way to reach the containing function.call.  Every PC address
should have a .call and .return, and could be contained in one or more
.inline nests as well.  Since the inlines cause ambiguity, and may get
in the way of reaching the .call, I think we should do away with this.

So IMO, get rid of the .function(NUM).inline binding, and make sure that
addresses in an inline still reach out to the containing .call.

Josh

Re: Does This Probe Make Sense?

[Mark Wielaard]

On Tue, 2011-08-30 at 09:38 -0700, Josh Stone wrote:
> On 08/30/2011 08:37 AM, Dave Brolley wrote:
> > I ran across this while writing the unprivileged_all.exp test suite last 
> > week.  I was unable to create an example for which a probe of the form:
> > 
> >      process.function(ADDRESS).inline
> > 
> > would resolve. It was suggested by fche that this probe didn't make much 
> > sense to him in the first place. I would like to arrive at a definitive 
> > answer. Does this probe make any sense and, if so, can someone provide 
> > an example?
> 
> Hmm, I found one:
> 
> > $ stap -l 'process("stap").function("main")'
> > process("/usr/local/bin/stap").function("main@../main.cxx:935")
> > $ stap -l 'process("stap").function("main")' -vv |& grep pc=
> > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> > $ stap -l 'process("stap").function(0x40d510).*'
> > process("/usr/local/bin/stap").function(0x40d510).call
> > process("/usr/local/bin/stap").function(0x40d510).return
> > $ stap -l 'process("stap").function(0x40d510).*' -vv |& grep pc=
> > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510
> > $ stap -l 'process("stap").function(0x40d610).*'
> > process("/usr/local/bin/stap").function(0x40d610).inline
> > $ stap -l 'process("stap").function(0x40d610).*' -vv |& grep pc=
> > probe size@/usr/lib/gcc/x86_64-redhat-linux/4.6.0/../../../../include/c++/4.6.0/bits/stl_vector.h:570 process=/usr/local/bin/stap reloc=.absolute pc=0x40d5fd
> 
> But I don't like that behavior, especially since the last one doesn't
> have any way to reach the containing function.call.

That is indeed surprising. If function(ADDR).inline worked, I would have
expected it to select the function at ADDR plus all inlined copies. But
it seems it is the opposite (at ADDR there is an inlined function). The
current behavior probably isn't very useful.

>   Every PC address
> should have a .call and .return, and could be contained in one or more
> .inline nests as well.  Since the inlines cause ambiguity, and may get
> in the way of reaching the .call, I think we should do away with this.
> 
> So IMO, get rid of the .function(NUM).inline binding, and make sure that
> addresses in an inline still reach out to the containing .call.

What do you mean by that last statement about "reach out"?

Thanks,

Mark

Re: Does This Probe Make Sense?

[Josh Stone]

On 09/06/2011 08:04 AM, Mark Wielaard wrote:
>> So IMO, get rid of the .function(NUM).inline binding, and make sure that
>> addresses in an inline still reach out to the containing .call.
> 
> What do you mean by that last statement about "reach out"?

Perhaps "reach up" would have been better, as in up the die hierarchy. I
meant that given an address within an inline instance, we should still
get a probe on the containing function.

Josh