From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Frank Ch. Eigler" <fche@redhat.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 17:21:02 +0100 [thread overview]
Message-ID: <20100119162059.GF8061@nowhere> (raw)
In-Reply-To: <20100119151210.GC16096@redhat.com>
On Tue, Jan 19, 2010 at 10:12:10AM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> > > > [...]
> > > > What about extending ptrace to support a new type of
> > > > breakpoint debugging interface?
> > >
> > > This is the sort of reason why the utrace-gdbstub prototype was
> > > constructed. It should allow in-kernel implementation of the
> > > multithreaded gdb extensions. (By the way, it can already use uprobes
> > > rather than userspace-managed breakpoints.)
> >
> > Can utrace somehow meet Joshua's needs?
>
> Not directly, I'm afraid. I jumped in at a late stage of the thread
> that got a bit away from Joshua's original note
> (http://lkml.org/lkml/2010/1/13/490). OTOH, it could be made to work
> a few different ways.
>
> One is a systemtap or hand-written module that maps selected
> perf-event hits in the kernel to an application SIGTRAP.
Yeah would work.
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).
> Another is using the gdbstub, extended with gdb watchpoint support (Z*
> packets), which would tie into the hw-breakpoint system directly.
> Joshua's application would manage the debug registers by means of a
> userspace supervisor process sending the appropriate Z* packets to the
> gdbstub, and otherwise letting the program run. When a watchpoint
> fires, the supervisor process can instruct gdbstub to send a SIGTRAP
> to the application. In this scenario, the perf syscall / subsystem is
> not used at all.
Is this gdbstub an interface to utrace?
This: http://lwn.net/Articles/364268/ ?
>
> > I'm not sure what kind of interface it can offer for that. The fact
> > is I don't know very well utrace :)
>
> That's ok. utrace is an in-kernel API for process management. ptrace
> and the RFC gdbstub are two possible userspace interfaces tuned for
> third-party debugging.
Ok.
>
> > 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 hope it gets plopped into linux-next ASAP and merged next
> time. The gdbstub was an RFC only at this stage, but if other people
> get excited about it, we're happy to spiff it up for proposed merging.
Ok.
Thanks.
next prev parent reply other threads:[~2010-01-19 16:21 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 [this message]
2010-01-19 16:26 ` Peter Zijlstra
2010-01-19 17:44 ` Frank Ch. Eigler
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=20100119162059.GF8061@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=andi@firstfloor.org \
--cc=fche@redhat.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.