This is the mail archive of the systemtap@sourceware.org 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: Does This Probe Make Sense?


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


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