From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: systemtap@sources.redhat.com
Subject: Re: user kprobes vs debuggers
Date: Mon, 06 Feb 2006 09:58:00 -0000 [thread overview]
Message-ID: <20060206095835.GA6484@in.ibm.com> (raw)
In-Reply-To: <20060202192231.GA29179@redhat.com>
On Thu, Feb 02, 2006 at 02:22:31PM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> During the teleconference earlier today, we discussed the issue of
> coexistence of user-mode kprobes (along the favoured #4 path) with
> debuggers, manipulating the same tasks.
>
> The core issue is that both systems insert breakpoints into pages
> of the target text. Ideally, we would like both systems to operate
> independently, unaware of each other. But:
>
> Without synchronization over "ownership" of the text pages, two
> systems may perform the insertion or removal interleaved in an
> inconvenient way. It may be possible to lose breakpoints, or even to
> create spontaneous ones. To perform sufficient synchronization, we
> may need to (a) detect possible conflicts after the fact, (b) bluntly
> block one system when the other is active, (c) hook user-kprobes into
> ptrace and /proc/mem code paths to intercept debuggers' operations
> and/or (d) provide a virtualization facility where the user-space
> tools only see a kprobe-less image of the real text page.
>
> A related problem is handling of breakpoints once triggered. Clearly
> user-kprobes get to run first. The system needs to know whether user
> space has also set a breakpoint at the same spot, so a subsequent
> ptrace signal can be propagated to the debugger. Some peculiar
> applications may put breakpoints into themselves even without a
> debugger present, expecting to catch SIGTRAP. Ideally, user kprobes
> should work with these too.
Just as a datapoint, atleast on PowerPC, kprobes (and xmon) use a
different "BREAKPOINT" opcode from the one used by GDB so, handling most
cases above should be trivial. In fact, we already handle the
possibility that a different debugger/trace tool may have inserted a
breakpoint at a given location (ref: is_trap() in kernel sources).
Breakpoints at the same address in userspace is a more tricky issue
though.
Ananth
next prev parent reply other threads:[~2006-02-06 9:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-02 19:22 Frank Ch. Eigler
2006-02-03 6:37 ` Vara Prasad
2006-02-03 8:04 ` Mathieu Lacage
2006-02-03 16:12 ` Vara Prasad
2006-02-06 9:58 ` Ananth N Mavinakayanahalli [this message]
2006-02-09 13:59 ` Richard J Moore
2006-02-03 17:43 Stone, Joshua I
2006-02-03 18:39 ` Vara Prasad
2006-02-03 20:29 Stone, Joshua I
2006-02-03 21:08 ` James Dickens
2006-02-03 22:00 ` Vara Prasad
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=20060206095835.GA6484@in.ibm.com \
--to=ananth@in.ibm.com \
--cc=fche@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).