Message-ID: <20100130204409.GE5675@nowhere>
Date:	Sat, 30 Jan 2010 21:44:10 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Benjamin Herrenschmidt <benh@....ibm.com>
Cc:	prasad@...ux.vnet.ibm.com, shaggy@...ux.vnet.ibm.com,
	linuxppc-dev@...abs.org, David Gibson <dwg@....ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers
	through extended ptrace interface

On Mon, Jan 25, 2010 at 07:32:00AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote:
> > 
> > Some of the benefits of using these generic interfaces include:
> > - Interoperability with other users of debug register (such as
> > parallel
> >   kernel requests) i.e. non-exclusive use of debug registers.
> > - Enables debugging/tracing tools such as perf-events and ftrace to
> > make
> >   use of debug registers.
> > - Re-use of common code available in kernel (kernel/hw_breakpoint.c).
> > 
> > Let me know what you think.
> 
> This might have changed but last I looked the "generic" breakpoint
> interface was still too x86-centric and wasn't capable of expressing
> some of the features of the BookE debug register set such as the data
> value compare, the ranged breakpoints, etc...



We have one field for addr, one for len and one for the memory access
type.

I think that those three are enough to express breakpoint ranges.
Basically a breakpoint range is a breakpoint that can have a high
len.

I've looked at the G2 PowerPc core breakpoint implementation, just to
face one of such tricky examples.

We have DABR and DABR2 for watchpoint (and respectively IABR and IABR2
for ins breakpoints). Those host the addresses to target, or well,
let's rather call them "address operand" registers. To generalize, I
call these xABR and xABR2 as it seems instruction and data breakpoint
work the same, they just have their own dedicated registers.

Then you have DBCR/IBCR (let's call them xBCR) which control the
breakpoints, with two fields in each that detail the operators to affect
in the address operands registers. You can choose betwen ==, <, or >= .

Another field in the operator is the SIG_TYPE, which describes the
combination, either "matches xABR AND xABR2" or "matches xABR OR xABR2".

If you choose the "OR" SIG_TYPE, it makes no sense to use the < or >=
operators on the addresses operands in practice. Who needs the following
matches?

	addr < xABR || addr >= xABR2
	addr < xABR || addr < xABR2
	addr >= xABR || addr >= xABR2

The only operator that makes sense in a OR type is ==, which
basically provides you two breakpoints:

	addr == xABR || addr == xABR2

Now if you choose the "AND" SIG_TYPE, the following matches
make no sense:

	addr < xABR && addr < xABR2
	addr < xABR && addr >= xABR2 (if xABR < xABR2)
	addr == xABR && addr (>=,<) xABR2

Basically, it's only usable for delimited ranges:

	addr >= xABR && addr < xABR2 (xABR < xABR2)

So the comparison is a trick that can actually only have
a practical use to define two exact matching breakpoints
or a delimited breakpoint range.

Hence, unless I'm missing something obvious, the current
generic interface is sufficient to express that.

I may also miss other kind of implementation that could
have other requirements.

 
> I'd rather have this more dedicated and more complete interface merged
> for gdb's sake, and in a second step look at unifying.


Perhaps. Supporting ptrace breakpoints should be an easy first
step as it's basically the responsibility of the user to fill
the registers, but it's a pretty limited scope work, especially you
won't have perf support.


> I believe that the generic breakpoint infrastructure should not be the
> mid-layer. IE. It cannot be made in any clean shape of form, to express
> all of the subtle features that a given architecture or platform can
> support and as such would always be inferior to a dedicated one.


Actually I think the current interface already does, as I explained
above.

What is broken for any other architectures than x86 is the set
of constraints, but I can easily move it to the arch, unless
I find a good generic solution (or a cool combination between
both).



> I can see the interest in exposing some kind of generic API that
> implements a common subset of breakpoint or watchpoint facilities to
> generic code such as the event tracer. This could be layered on top of
> an arch specific mechanism
> 
> But having the generic mechanism at the core for everybody is another
> attempt of "make everybody look like x86" which I believe in this case
> is sub optimal.


Not at all. It's an attempt to make a generic interface that can
exploit at best _each_ arch specific features. Other than the set
of constraints that I'm going to rework, the generic interface is powerful
enough to host what I've seen in term of cpu breakpoints implementations
for now. But if it's actually not and I'm missing other cases, please
report it to me.

The reason that makes the current generic constraints x86
oriented only is that I've only x86 boxes at home and I needed
to make a first shot without knowing anything about other archs
constraints, but in the long term, our motivations (Prasad's and mines)
are definetely not archX-centric.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists