Message-ID: <1264887205.8287.5.camel@pasglop>
Date:	Sun, 31 Jan 2010 08:33:25 +1100
From:	Benjamin Herrenschmidt <benh@....ibm.com>
To:	Frederic Weisbecker <fweisbec@...il.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


> 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.

BookE has a richer semantic. We have watchpoints with data value compare
for example, we also have instruction value compare for breakpoints, and
a few other niceties. There's also subtle differences between what
processor variants support.

 .../...

> > 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.

But we can add it later. 

> > 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).

Again, this is all "can do" vs. "already done and working". May I point
you to Linus recent rant against magic infrastructures that try to do
everything and do nothing right ? :-) I much prefer starting with
something dedicated that does exactly what is expected, have that
upstream (and in that regard the patches are good for the next merge
window) and -then- maybe look at how some of it could be re-used for
perf.

> Not at all. It's an attempt to make a generic interface that can
> exploit at best _each_ arch specific features. 

That reminds me of the justifications for utrace :-) It might well be
but I very much doubt that is possible. In any case, it doesn't appear
to be there yet. So let's just get that stuff in so we have our
interface finally working, and we can look at doing fancy things with
perf in a second pass.

> 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.

Cheers,
Ben.


--
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