Re: [RFC PATCH 1/2] hw-breakpoints: Separate constraint space for data and instruction breakpoints

[Frederic Weisbecker <fweisbec@gmail.com>]

On Fri, Apr 16, 2010 at 03:35:30PM +0100, Will Deacon wrote:
> Hello Frederic,
> 
> Thanks for this.
> 
> On Tue, 2010-04-13 at 00:01 +0100, Frederic Weisbecker wrote:
> > There are two outstanding fashions for archs to implement hardware
> > breakpoints.
> > 
> > The first is to separate breakpoint address pattern definition
> > space between data and instruction breakpoints. We then have
> > typically distinct instruction address breakpoint registers
> > and data address breakpoint registers, delivered with
> > separate control registers for data and instruction breakpoints
> > as well. This is the case of PowerPc and ARM for example.
> > 
> > The second consists in having merged breakpoint address space
> > definition between data and instruction breakpoint. Address
> > registers can host either instruction or data address and
> > the access mode for the breakpoint is defined in a control
> > register. This is the case of x86.
> > 
> > This patch adds a new CONFIG_HAVE_MIXED_BREAKPOINTS_REGS config
> > that archs can select if they belong to the second case. Those
> > will have their slot allocation merged for instructions and
> > data breakpoints.
> > 
> > The others will have a separate slot tracking between data and
> > instruction breakpoints.
> 
> This looks useful for supporting architectures with separate
> data/instruction breakpoints.
> 
> A couple of points:
> 
> 1.) Will this affect the arch backend at all?


No change is required from the backend. In fact this config probably
only fits for x86, unless there are other archs that have shared
register addresses... Archs that only support data or inst breakpoints
should also select it, but only to save a bit of memory, there would
be no functional changes.


 
> 2.) On ARM, it is possible to have different numbers of breakpoint registers
>     and watchpoint registers [which we do not know until runtime]. This
>     means that we have to define HBP_NUM as a potential upper bound,
>     which seems a bit wasteful. Perhaps there could be a mechanism to 
>     register the available resources at runtime?


Ah that's interesting. Ok, I will update my patch to integrate that.