public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: David Smith <dsmith@redhat.com>
Cc: Josh Stone <jistone@redhat.com>,
	systemtap@sourceware.org,
	       Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: Initial stap support for inode-based uprobes
Date: Thu, 17 Nov 2011 09:52:00 -0000	[thread overview]
Message-ID: <1321523534.3442.14.camel@springer.wildebeest.org> (raw)
In-Reply-To: <4EC3F556.4010902@redhat.com>

On Wed, 2011-11-16 at 11:39 -0600, David Smith wrote:
> > * Probe IP.  For many probe handlers, we try to set the pt_regs IP to
> > the actual breakpoint IP, but in this case we don't happen to even know
> > the virtualized address.  Uprobes itself uses uprobes_get_bkpt_addr() in
> > some instances, but that's not exposed for our use.

This is really architecture dependent, we just currently do it by
querying kprobes or uprobes where the breakpoint was set. On some
architectures (x86 at least) the PC gets munged during the breakpoint
processing (it is set after the breakpoint instruction on that
architecture), which causes some confusion for some of the runtime or
scripts which look at the REG_IP and see something different than they
expect (in the worst case the PC is just after the current function or
module). If you cannot get at the actual breakpoint address you will
need to resort to architecture specific code, that know the breakpoint
instruction used and how much the PC should be adjusted (normally the
width of the breakpoint instruction).

uprobe_stmt_num.exp and uprobe_uaddr.exp are the tests to look at. But
also tests that do unwinding rely on REG_IP being somewhat sane.

Cheers,

Mark

  parent reply	other threads:[~2011-11-17  9:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20  3:24 Josh Stone
2011-11-16 19:05 ` David Smith
2011-11-16 19:05   ` Josh Stone
2011-11-17  9:28   ` Mark Wielaard
2011-11-29 21:21     ` David Smith
2011-11-17  9:52   ` Mark Wielaard [this message]
2011-11-17 10:06   ` Mark Wielaard
2011-11-30  5:39   ` David Smith
2011-11-30 14:01     ` Srikar Dronamraju

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=1321523534.3442.14.camel@springer.wildebeest.org \
    --to=mjw@redhat.com \
    --cc=dsmith@redhat.com \
    --cc=jistone@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sourceware.org \
    /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).