Re: HW breakpoints perf_events request
From: Frank Ch. Eigler
Date: Tue Jan 19 2010 - 10:12:34 EST
> > > [...]
> > > 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.
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.
> 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
> 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. 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/