public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Prasad <prasad@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>,
	Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH 1/2] hw-breakpoints: Perf interface support for breakpoint ranges
Date: Fri, 4 Dec 2009 22:00:06 +0100	[thread overview]
Message-ID: <20091204205959.GA13473@nowhere> (raw)
In-Reply-To: <1259896133.2076.1254.camel@pasglop>

On Fri, Dec 04, 2009 at 02:08:53PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-12-03 at 22:16 +0100, Frederic Weisbecker wrote:
> > Looking a the PowerPc cpu implementations of breakpoints, we have
> > for both data and instruction breakpoints:
> > 
> > - 2 Address registers (let's rather talk about a comparison operand)
> > - Control registers that define the comparison nature (equal, greater,
> >   lesser than) against the above addresses.
> > - Control registers that define how to handle the 2 address registers.
> >   The instruction address or memory access need to either match
> >    - Address 1 OR Address 2 (OR = boolean OR, not binary)
> >    - Address 1 AND Address 2 ( AND = boolean AND, not binary)
> >   And this match is subject to the comparison rules independantly
> >   defined for these two addresses by the control registers
> 
> Well.. the debug facility is different between different PowerPC CPU
> families... There's range breakpoints on some but not all, there's data
> value compare or even instruction value compare on some, etc...



Sure.
I've picked this example (Freescale G2 PPC) as it looks one the trickiest
implementations.


 
> > The most obvious practical uses of these facilities are either the
> > definition of two independant traditional breakpoints, or the
> > definition of a breakpoint that matches a range of addresses.
> > 
> > Hence we want the generic breakpoint interface to support it.
> > This patch splits up the struct perf_event_attr::bp_addr field
> > into bp_start and bp_end.
> 
> Ok, that sounds like a good idea.
> 
> > The definition of a simple breakpoint needs bp_start and bp_end to be
> > equal, ie: a simple breakpoint is a range breakpoint which start and
> > end addresses are identical.
> 
> Ok. So a 0 sized point. Makes sense.



Now that I think about it.
Why not actually use the bp_len field. It was first meant to determine
the size of the access (1, 2, 4, 8 in x86). But that could be extended
to define ranges if breakpoint ranges imply accesses of random size.

What do you think? If the PowerPc range breakpoints are always for
random size accesses (I'm not sure about it), then that would make
sense.

In this case we should drop this patch as the current interface is already
fine. We just need to turn bp_len into a u64 (u32 may not cover every cases).



> > To define a range breakpoint, you just need to set bp_start and bp_end
> > to the limits of your address range.
> 
> Inclusive ?



Yeah, that probably makes more sense as a default.


      reply	other threads:[~2009-12-04 21:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-03 21:16 [PATCH 1/2] hw-breakpoints: Perf interface support for breakpoint ranges Frederic Weisbecker
2009-12-03 21:16 ` [PATCH 2/2] hw-breakpoints: Add two reserved fields for future extensions Frederic Weisbecker
2009-12-03 21:33   ` Peter Zijlstra
2009-12-03 22:20     ` [PATCH] perf: Remove pointless union that wraps the hw breakpoint fields Frederic Weisbecker
2009-12-04  3:08 ` [PATCH 1/2] hw-breakpoints: Perf interface support for breakpoint ranges Benjamin Herrenschmidt
2009-12-04 21:00   ` Frederic Weisbecker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091204205959.GA13473@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@redhat.com \
    --cc=benh@kernel.crashing.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox