From: "Frank Ch. Eigler" <fche@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Joshua Pincus <joshua.pincus@gmail.com>,
Andi Kleen <andi@firstfloor.org>,
"K.Prasad" <prasad@linux.vnet.ibm.com>,
peterz@infradead.org, paulus@samba.org, acme@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: HW breakpoints perf_events request
Date: Tue, 19 Jan 2010 12:44:14 -0500 [thread overview]
Message-ID: <20100119174414.GE16096@redhat.com> (raw)
In-Reply-To: <20100119162059.GF8061@nowhere>
Hi -
On Tue, Jan 19, 2010 at 05:21:02PM +0100, Frederic Weisbecker wrote:
> [...]
> But I rather hope we can extend ptrace interface to handle such new
> needs instead (ie: having a more scalable breakpoint interface
> support by ptrace).
According to its maintainer, ptrace per se appears to be not well
suited for extensions that affect control flow, but maybe.
(http://www.mail-archive.com/utrace-devel@redhat.com/msg02276.html)
> > Another is using the gdbstub, extended with gdb watchpoint support (Z*
> > packets), which would tie into the hw-breakpoint system directly.
> > [...]
> Is this gdbstub an interface to utrace?
> This: http://lwn.net/Articles/364268/ ?
Yes, but I wouldn't think of it that way ("an interface to utrace").
Yes, it uses utrace, but that's an implementation detail. To
userspace it presents gdb's existing wire protocol for debugging
processes.
> > > Do you plan a resubmission soon?
> >
> > Utrace core has been resubmitted at the end of December
> > (http://lkml.org/lkml/2009/12/17/466), with no further comments
> > received.
>
> Hmm, there has been deep review from Peter, IIRC.
I haven't seen any after that particular resubmission. Rather, there
has been lots of discussion lately about *uprobes*, which is a
separate & optional process breakpoint management layer that happens
to use utrace and happens to be used by systemtap and the gdbstub.
- FChE
next prev parent reply other threads:[~2010-01-19 17:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 1:45 HW breakpoints perf_events request Joshua Pincus
2010-01-14 2:15 ` Andi Kleen
2010-01-14 2:21 ` Joshua Pincus
2010-01-14 9:23 ` Andi Kleen
2010-01-14 18:03 ` Joshua Pincus
2010-01-18 11:04 ` Frederic Weisbecker
2010-01-18 11:35 ` Andi Kleen
2010-01-19 14:40 ` Frederic Weisbecker
2010-01-18 16:33 ` Frank Ch. Eigler
2010-01-19 14:50 ` Frederic Weisbecker
2010-01-19 15:12 ` Frank Ch. Eigler
2010-01-19 16:21 ` Frederic Weisbecker
2010-01-19 16:26 ` Peter Zijlstra
2010-01-19 17:44 ` Frank Ch. Eigler [this message]
2010-01-14 5:10 ` Frederic Weisbecker
2010-01-14 8:44 ` Peter Zijlstra
2010-01-14 18:02 ` Joshua Pincus
2010-01-18 17:45 ` K.Prasad
2010-01-19 14:53 ` Frederic Weisbecker
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=20100119174414.GE16096@redhat.com \
--to=fche@redhat.com \
--cc=acme@redhat.com \
--cc=andi@firstfloor.org \
--cc=fweisbec@gmail.com \
--cc=joshua.pincus@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=prasad@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.