Re: Does This Probe Make Sense?

[Mark Wielaard <mjw at redhat dot com>]

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