This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Does This Probe Make Sense?
- From: Josh Stone <jistone at redhat dot com>
- To: Dave Brolley <brolley at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Tue, 30 Aug 2011 09:38:20 -0700
- Subject: Re: Does This Probe Make Sense?
- References: <4E5D03D3.4010208@redhat.com>
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