Re: HW breakpoints perf_events request

[Andi Kleen <andi@firstfloor.org>]

On Mon, Jan 18, 2010 at 12:04:07PM +0100, Frederic Weisbecker wrote:
> I don't quite understand what signals are masked here,

ptrace reports all signals to the tracer and only
delivers them on PTRACE_CONT. "Masking" is probably
not the right term for it.

This could be fixed relatively easily with a new signal
mask ptrace option I guess.

> actually I'm not sure what is the true problem with ptrace.
> Is it because a breakpoint in a thread is going to stop
> all thread in the process until the parent handles the
> signal?

I didn't think ptrace stopped all threads by its own,
it just stops the current one and also only until 
the problem is reported. And for a break point you
typically want (in fact need to) to stop until it is handled.

> 
> Anyway, although I first suggested extending perf, with
> more thoughts I now agree that perf should keep doing what
> it does currently (profiling) and not trying to become an
> messy mix of a profiler, debugger, etc...

I find it surprising that you say that -- my
impression is that whatever gets proposed recently: 
error injection, testing, error handling, any other event 
someone proposed perf as the answer.

"If all I got is a hammer everything starts to look like a thumb"

But yes I fully agree with you.


> What about extending ptrace to support a new type of
> breakpoint debugging interface?

There's this utrace interface, but it seems to be more
a in kernel layer with some "we can't make up our mind what
the interface to the user looks like" and a lot of
overengineering in interfaces thrown in.

ptrace in its current form is somewhat messy, but for
me it seems there isn't anything better. So yes extending
it would seem like a good idea.

A good starting point might be the debug store interfaces
that got recently added to ptrace.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.