public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Josh Stone <jistone@redhat.com>
To: Dave Brolley <brolley@redhat.com>
Cc: systemtap@sources.redhat.com
Subject: Re: Does This Probe Make Sense?
Date: Tue, 30 Aug 2011 16:38:00 -0000	[thread overview]
Message-ID: <4E5D11FC.8060009@redhat.com> (raw)
In-Reply-To: <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

  reply	other threads:[~2011-08-30 16:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-30 15:38 Dave Brolley
2011-08-30 16:38 ` Josh Stone [this message]
2011-09-06 15:05   ` Mark Wielaard
2011-09-06 17:32     ` Josh Stone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E5D11FC.8060009@redhat.com \
    --to=jistone@redhat.com \
    --cc=brolley@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).