Re: [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events

[Paul Mackerras <paulus@samba.org>]

Frederic Weisbecker writes:

> This patch rebase the implementation of the breakpoints API on top of
> perf events instances.
> 
> Each breakpoints are now perf events that handle the
> register scheduling, thread/cpu attachment, etc..

What I haven't managed to understand yet is how you provide reliable
breakpoints for debugging purposes.  If I'm debugging a program and I
have set a breakpoint, I'll be very unhappy if the breakpoint should
trigger but doesn't because the perf_event infrastructure has decided
it can't schedule that breakpoint in.  If the breakpoint isn't going
to work then I want to know that at the time that I set it.

We can go some distance towards that with the pinned attribute, but
not far enough.  The pinned attribute doesn't guarantee that the event
will always be scheduled in, it just says that we'll do our best to
schedule it in, and if we can't, we'll put the event into error state
so that the user knows we didn't manage to schedule it in.  But
there's no way to get back to gdb and tell it that a breakpoint that
it had previously successfully created is no longer working.

Also, we don't currently fail the creation of a pinned event if it
would conflict with another pinned event already created in the same
context.  We would need to do something like that if we want to use
pinned events for debugging breakpoints (as distinct from breakpoints
for performance monitoring purposes, for which it matters less if they
are sometimes not scheduled in).

And then there's the question of whether a per-cpu pinned breakpoint
event conflicts with a per-task pinned breakpoint event if you only
have one breakpoint register (as is the case on Power server CPUs).
Plus the fact that we don't currently give per-task pinned events
priority over per-cpu non-pinned events (perhaps that would be a good
idea anyway).

Paul.