Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[K.Prasad]

>From shaggy at linux.vnet.ibm.com  Tue Jan 19 08:57:04 2010
From: shaggy at linux.vnet.ibm.com (Dave Kleikamp)
Date: Mon, 18 Jan 2010 14:57:04 -0700
Subject: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through
	extended ptrace interface
Message-ID: <20100118215704.15684.60646.sendpatchset@norville.austin.ibm.com>

> These patches implement an extention to the ptrace interface proposed by
> Thiago Bauermann and the the PowerPC gdb team.

(Using the plain text from mail archive..mail may not be in the usual
mail-reply format...kindly bear).

Hi,
  First of all, thanks for bringing this patch that puts the debug
registers in BookE to good use! I learnt about this patch submission
only recently...please see some of my concerns as under.

Given that there now exists generic kernel interfaces to use
hw-breakpoints - register_user_hw_breakpoint() and
unregister_hw_breakpoint() (available in mainline since 2.6.33-rc1), it
would be prudent to use them for the ptrace requests (that are made in
arch_ptrace()).

This would mean that some of the arch-specific debug register code that
read/write from/to the debug registers of Book-E may have to be in a
form that closely resembles arch/<x86><power>/kernel/hw_breakpoint.c 

A patch that enables arch-specific code for PPC64 is already submitted
(linuxppc-dev ref: 20100121084640.GA3252@in.ibm.com). This converts
ptrace requests for PTRACE_<GET><SET>_DEBUGREG flags to use the
above-mentioned interfaces for PPC64.

If you intend to re-write this patch to use the generic hw-breakpoint
interfaces (which I strongly recommend you to do, for the reasons mentioned
below), I would be more than glad to help you port them.

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.

Thanks,
K.Prasad

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Benjamin Herrenschmidt]

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

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

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.

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.

Again, I might have missed some evolutions of the latest versions of
your infrastructure that would make it good enough to fully bridge the
gap with our requirements, and I'll let Shaggy decide here what he wants
to do. But I will not block his current patches neither if he thinks
that they are good enough as is.

Cheers,
Ben.

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[K.Prasad]

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...
> 
> I'd rather have this more dedicated and more complete interface merged
> for gdb's sake, and in a second step look at unifying.
> 

While the hw-breakpoint infrastructure is more generic (than
what can be termed x86-centric), it cannot support sophisticated
features like DVC register - atleast in its present form.

My idea was to align the Book-E processor's use of debug registers with
the existing breakpoint framework, and in the process make improvements/
changes to the common framework as necessitated.

It could be done in a two-step process to ease the development and review
process (more on this below).

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

Given the diversity of debug register implementation (across
processors), concerns about having a poorly-featured mid-layer is
understandable.

But our design goal is to be as flexible as required to accomodate newer
architectures, while providing them the benefit of using the common
framework - such as register arbitration (existing implementation would
assume mutually exclusive access to debug registers), scheduling and
abstraction through generic interfaces.

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

No, it is not! In fact patches that port the framework to PPC64 and S390
have already been posted to the respective communities and are under
review.

> Again, I might have missed some evolutions of the latest versions of
> your infrastructure that would make it good enough to fully bridge the
> gap with our requirements, and I'll let Shaggy decide here what he wants
> to do. But I will not block his current patches neither if he thinks
> that they are good enough as is.
> 

As I mentioned above, the generic framework may need to be extended to
support all features required by processors such as Book-E. Any
feature that is very unique to a given processor and exotic to the
hw-breakpoint framework can be kept outside its purview (and implemented
to support only ptrace with exclusive access to those registers).

Sure, let's wait to hear from Shaggy to know how he'd like to proceed. 

Thanks,
K.Prasad

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Frederic Weisbecker]

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.

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Benjamin Herrenschmidt]

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

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Frederic Weisbecker]

On Sun, Jan 31, 2010 at 08:33:25AM +1100, Benjamin Herrenschmidt wrote:
> 
> > 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.
> 
>  .../...



Ah indeed, I missed the data value compare thing. Especially how
it is implemented won't make things easy.

This is basically a comparison against chosen bytes of the data,
with or/and patterns.

Not sure what the "or" can be useful for.

That won't be easy to implement in the generic interface, looking
at how it is done in the BookE.

There is also the address comparison by mask.

Anyway, I think we can add fields in the interface to provide
such features, but we can't support all of them given, as you
said, the subtle differences between different cpu.

For example I think it can be useful to implement support
for data comparison, by mask for example. But I don't imagine
useful usecases to compare byte 4 and byte1 and trigger an event
if one OR other match.

I think we are going to implement what has obvious usecases
(parts of such data comparisons, parts of address mask
comparison) in the generic interface: the fields in perf_attr
that can be filled by perf in userspace.
And the rest can be implemented from the hw_perf_event structure
which contains the arch structure and can then be filled by ptrace at
will.


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



Yeah you're right. Having a raw ptrace support is a first
useful step that won't be a barrier to enhance it further
through the generic API.


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


Sure I'm not against a first raw ptrace support. As I said,
this is not a barrier for what comes next.

Now for the rest, I don't think this is the same story than
utrace.

Trying to have a generic layer for a hardware feature implemented
differently across archs can't be called something that tries to do
everything. Otherwise you can oppose these arguments to everything
that is not in the arch/ directories. No generic irq layer, no
generic timer, etc...

We need this generic layer because we want the breakpoints
to be available for wider uses than ptrace. If there was only
ptrace, I would really agree with you that it's not worth the
generic layer.

It's just that breakpoints are a set of possible features, but each
archs implement its own subset among the possible features. x86
is one of the weakest there, and since this generic layer has been
first x86 oriented, it looks too weak to host the most interesting
possibilities.

Let it grow a bit, it's still young.


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


You are too pessimistic ;-)

I don't think we can express every possibilities through the generic
interface. But we can express the most interesting ones for profiling
uses.

The rest (ptrace) can still be expressed through the arch part of the perf
events.


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


Sure.

[RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

These patches implement an extention to the ptrace interface proposed by
Thiago Bauermann and the the PowerPC gdb team.

This is a resubmission of the patches I first sent on December 9th.
Sorry for the delay.  I have addressed most of the comments, and I'll
follow up on the others.

These patches are based on 2.6.33-rc3.  (Nothing really changed in powerpc
between rc3 & rc4.)  These patches still need some testing, but I want
to get the ball rolling again.

The following has been added as Documentation/powerpc/ptrace.txt:

GDB intends to support the following hardware debug features of BookE
processors:

4 hardware breakpoints (IAC)
2 hardware watchpoints (read, write and read-write) (DAC)
2 value conditions for the hardware watchpoints (DVC)

For that, we need to extend ptrace so that GDB can query and set these
resources. Since we're extending, we're trying to create an interface
that's extendable and that covers both BookE and server processors, so
that GDB doesn't need to special-case each of them. We added the
following 3 new ptrace requests.

1. PTRACE_PPC_GETHWDEBUGINFO

Query for GDB to discover the hardware debug features. The main info to
be returned here is the minimum alignment for the hardware watchpoints.
BookE processors don't have restrictions here, but server processors have
an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
adding special cases to GDB based on what it sees in AUXV.

Since we're at it, we added other useful info that the kernel can return to
GDB: this query will return the number of hardware breakpoints, hardware
watchpoints and whether it supports a range of addresses and a condition.
The query will fill the following structure provided by the requesting process:

struct ppc_debug_info {
       unit32_t version;
       unit32_t num_instruction_bps;
       unit32_t num_data_bps;
       unit32_t num_condition_regs;
       unit32_t data_bp_alignment;
       unit32_t sizeof_condition; /* size of the DVC register */
       uint64_t features; /* bitmask of the individual flags */
};

features will have bits indicating whether there is support for:

#define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
#define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8

2. PTRACE_SETHWDEBUG

Sets a hardware breakpoint or watchpoint, according to the provided structure:

struct ppc_hw_breakpoint {
        uint32_t version;
#define PPC_BREAKPOINT_TRIGGER_EXECUTE  0x1
#define PPC_BREAKPOINT_TRIGGER_READ     0x2
#define PPC_BREAKPOINT_TRIGGER_WRITE    0x4
        uint32_t trigger_type;       /* only some combinations allowed */
#define PPC_BREAKPOINT_MODE_EXACT               0x0
#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE     0x1
#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE     0x2
#define PPC_BREAKPOINT_MODE_MASK                0x3
        uint32_t addr_mode;          /* address match mode */

#define PPC_BREAKPOINT_CONDITION_MODE   0x3
#define PPC_BREAKPOINT_CONDITION_NONE   0x0
#define PPC_BREAKPOINT_CONDITION_AND    0x1
#define PPC_BREAKPOINT_CONDITION_EXACT  0x1	/* different name for the same thing as above */
#define PPC_BREAKPOINT_CONDITION_OR     0x2
#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000	/* byte enable bits */
#define PPC_BREAKPOINT_CONDITION_BE(n)  (1<<((n)+16))
        uint32_t condition_mode;     /* break/watchpoint condition flags */

        uint64_t addr;
        uint64_t addr2;
        uint64_t condition_value;
};

A request specifies one event, not necessarily just one register to be set.
For instance, if the request is for a watchpoint with a condition, both the
DAC and DVC registers will be set in the same request.

With this GDB can ask for all kinds of hardware breakpoints and watchpoints
that the BookE supports. COMEFROM breakpoints available in server processors
are not contemplated, but that is out of the scope of this work.

ptrace will return an integer (handle) uniquely identifying the breakpoint or
watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.

Some examples of using the structure to:

- set a breakpoint in the first breakpoint register

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = 0;

- set a watchpoint which triggers on reads in the second watchpoint register

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = 0;

- set a watchpoint which triggers only with a specific value

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = (uint64_t) condition;

- set a ranged hardware breakpoint

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
  p.addr_mode       = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) begin_range;
  p.addr2           = (uint64_t) end_range;
  p.condition_value = 0;

3. PTRACE_DELHWDEBUG

Takes an integer which identifies an existing breakpoint or watchpoint
(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
corresponding breakpoint or watchpoint..

-- 
Dave Kleikamp
IBM Linux Technology Center

[RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

These patches implement an extention to the ptrace interface proposed by
Thiago Bauermann and the the PowerPC gdb team.

GDB intends to support the following hardware debug features of BookE
processors:

4 hardware breakpoints (IAC)
2 hardware watchpoints (read, write and read-write) (DAC)
2 value conditions for the hardware watchpoints (DVC)

For that, we need to extend ptrace so that GDB can query and set these
resources. Since we're extending, we're trying to create an interface
that's extendable and that covers both BookE and server processors, so
that GDB doesn't need to special-case each of them. We propose the
following 3 new ptrace requests described below.

There have been discussions of a generic hardware debug interface for the
kernel which would hopefully contemplate all the functionality below and
supersede it.  But we need something that works now, and which enables GDB
to be simpler and work with both Server and Embedded processors without
special cases.

1. PTRACE_PPC_GETHWDEBUGINFO

Query for GDB to discover the hardware debug features. The main info to
be returned here is the minimum alignment for the hardware watchpoints.
BookE processors don't have restrictions here, but server processors have
an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
adding special cases to GDB based on what it sees in AUXV.

Since we're at it, we added other useful info that the kernel can return to
GDB: this query will return the number of hardware breakpoints, hardware
watchpoints and whether it supports a range of addresses and a condition.
The query will fill the following structure provided by the requesting process:

struct ppc_debug_info {
       unit32_t version;
       unit32_t num_instruction_bps;
       unit32_t num_data_bps;
       unit32_t num_condition_regs;
       unit32_t data_bp_alignment;
       unit32_t sizeof_condition; /* size of the DVC register */
       uint64_t features; /* bitmask of the individual flags */
};

features will have bits indicating whether there is support for:

#define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
#define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
#define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8

2. PTRACE_SETHWDEBUG

Sets a hardware breakpoint or watchpoint, according to the provided structure:

struct ppc_hw_breakpoint {
        uint32_t version;
#define PPC_BREAKPOINT_TRIGGER_EXECUTE  0x1
#define PPC_BREAKPOINT_TRIGGER_READ     0x2
#define PPC_BREAKPOINT_TRIGGER_WRITE    0x4
        uint32_t trigger_type;       /* only some combinations allowed */
#define PPC_BREAKPOINT_MODE_EXACT               0x0
#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE     0x1
#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE     0x2
#define PPC_BREAKPOINT_MODE_MASK                0x3
        uint32_t addr_mode;          /* address match mode */

#define PPC_BREAKPOINT_CONDITION_NONE   0x0
#define PPC_BREAKPOINT_CONDITION_AND    0x1
#define PPC_BREAKPOINT_CONDITION_EXACT  0x1	/* different name for the same thing as above */
#define PPC_BREAKPOINT_CONDITION_OR     0x2
#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000	/* byte enable bits */
#define PPC_BREAKPOINT_CONDITION_BE(n)  (1<<((n)+16))
        uint32_t condition_mode;     /* break/watchpoint condition flags */

        uint64_t addr;
        uint64_t addr2;
        uint64_t condition_value;
};

A request specifies one event, not necessarily just one register to be set.
For instance, if the request is for a watchpoint with a condition, both the
DAC and DVC registers will be set in the same request.

With this GDB can ask for all kinds of hardware breakpoints and watchpoints
that the BookE supports. COMEFROM breakpoints available in server processors
are not contemplated, but that is out of the scope of this work.

ptrace will return an integer (handle) uniquely identifying the breakpoint or
watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
request to ask for its removal. Return -ENOSPC if the requested breakpoint
can't be allocated on the registers.

Some examples of using the structure to:

- set a breakpoint in the first breakpoint register

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = 0;

- set a watchpoint which triggers on reads in the second watchpoint register

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = 0;

- set a watchpoint which triggers only with a specific value

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
  p.addr            = (uint64_t) address;
  p.addr2           = 0;
  p.condition_value = (uint64_t) condition;

- set a ranged hardware breakpoint

  p.version         = PPC_DEBUG_CURRENT_VERSION;
  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
  p.addr_mode       = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
  p.addr            = (uint64_t) begin_range;
  p.addr2           = (uint64_t) end_range;
  p.condition_value = 0;

3. PTRACE_DELHWDEBUG

Takes an integer which identifies an existing breakpoint or watchpoint
(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
corresponding breakpoint or watchpoint..

-- 
Dave Kleikamp
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Kumar Gala]

On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:

> These patches implement an extention to the ptrace interface proposed =
by
> Thiago Bauermann and the the PowerPC gdb team.
>=20
> GDB intends to support the following hardware debug features of BookE
> processors:
>=20
> 4 hardware breakpoints (IAC)
> 2 hardware watchpoints (read, write and read-write) (DAC)
> 2 value conditions for the hardware watchpoints (DVC)
>=20
> For that, we need to extend ptrace so that GDB can query and set these
> resources. Since we're extending, we're trying to create an interface
> that's extendable and that covers both BookE and server processors, so
> that GDB doesn't need to special-case each of them. We propose the
> following 3 new ptrace requests described below.
>=20
> There have been discussions of a generic hardware debug interface for =
the
> kernel which would hopefully contemplate all the functionality below =
and
> supersede it.  But we need something that works now, and which enables =
GDB
> to be simpler and work with both Server and Embedded processors =
without
> special cases.
>=20
> 1. PTRACE_PPC_GETHWDEBUGINFO
>=20
> Query for GDB to discover the hardware debug features. The main info =
to
> be returned here is the minimum alignment for the hardware =
watchpoints.
> BookE processors don't have restrictions here, but server processors =
have
> an 8-byte alignment restriction for hardware watchpoints. We'd like to =
avoid
> adding special cases to GDB based on what it sees in AUXV.
>=20
> Since we're at it, we added other useful info that the kernel can =
return to
> GDB: this query will return the number of hardware breakpoints, =
hardware
> watchpoints and whether it supports a range of addresses and a =
condition.
> The query will fill the following structure provided by the requesting =
process:
>=20
> struct ppc_debug_info {
>       unit32_t version;
>       unit32_t num_instruction_bps;
>       unit32_t num_data_bps;
>       unit32_t num_condition_regs;
>       unit32_t data_bp_alignment;
>       unit32_t sizeof_condition; /* size of the DVC register */
>       uint64_t features; /* bitmask of the individual flags */
> };
>=20
> features will have bits indicating whether there is support for:
>=20
> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8

Is GDB smart enough to deal w/no condition_regs?  On some Book-E devices =
we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in the features?

- k=

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> 
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> > 
> > GDB intends to support the following hardware debug features of BookE
> > processors:
> > 
> > 4 hardware breakpoints (IAC)
> > 2 hardware watchpoints (read, write and read-write) (DAC)
> > 2 value conditions for the hardware watchpoints (DVC)
> > 
> > For that, we need to extend ptrace so that GDB can query and set these
> > resources. Since we're extending, we're trying to create an interface
> > that's extendable and that covers both BookE and server processors, so
> > that GDB doesn't need to special-case each of them. We propose the
> > following 3 new ptrace requests described below.
> > 
> > There have been discussions of a generic hardware debug interface for the
> > kernel which would hopefully contemplate all the functionality below and
> > supersede it.  But we need something that works now, and which enables GDB
> > to be simpler and work with both Server and Embedded processors without
> > special cases.
> > 
> > 1. PTRACE_PPC_GETHWDEBUGINFO
> > 
> > Query for GDB to discover the hardware debug features. The main info to
> > be returned here is the minimum alignment for the hardware watchpoints.
> > BookE processors don't have restrictions here, but server processors have
> > an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> > adding special cases to GDB based on what it sees in AUXV.
> > 
> > Since we're at it, we added other useful info that the kernel can return to
> > GDB: this query will return the number of hardware breakpoints, hardware
> > watchpoints and whether it supports a range of addresses and a condition.
> > The query will fill the following structure provided by the requesting process:
> > 
> > struct ppc_debug_info {
> >       unit32_t version;
> >       unit32_t num_instruction_bps;
> >       unit32_t num_data_bps;
> >       unit32_t num_condition_regs;
> >       unit32_t data_bp_alignment;
> >       unit32_t sizeof_condition; /* size of the DVC register */
> >       uint64_t features; /* bitmask of the individual flags */
> > };
> > 
> > features will have bits indicating whether there is support for:
> > 
> > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> > #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> > #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
> 
> Is GDB smart enough to deal w/no condition_regs?  On some Book-E
> devices we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in the
> features?

I had discussed it with the gdb team.  I could easily add a feature
flag, but it would be equivalent to num_condition_regs > 0.  I don't
have a strong opinion either way.
-- 
David Kleikamp
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Thiago Jung Bauermann]

On Fri 11 Dec 2009 00:27:36 Dave Kleikamp wrote:
> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> > On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> > > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> > > #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> > > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> > > #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
> >
> > Is GDB smart enough to deal w/no condition_regs?  On some Book-E
> > devices we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in the
> > features?
> 
> I had discussed it with the gdb team.  I could easily add a feature
> flag, but it would be equivalent to num_condition_regs > 0.  I don't
> have a strong opinion either way.

The current GDB code we have here uses num_condition_regs > 0 to discover if 
DVCs are supported, so a PPC_DEBUG_FEATURE constant for that is redundant 
IMHO.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Kumar Gala]

On Dec 11, 2009, at 2:07 PM, Thiago Jung Bauermann wrote:

> On Fri 11 Dec 2009 00:27:36 Dave Kleikamp wrote:
>> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
>>> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>>>> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
>>>> #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
>>>> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
>>>> #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
>>>=20
>>> Is GDB smart enough to deal w/no condition_regs?  On some Book-E
>>> devices we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in =
the
>>> features?
>>=20
>> I had discussed it with the gdb team.  I could easily add a feature
>> flag, but it would be equivalent to num_condition_regs > 0.  I don't
>> have a strong opinion either way.
>=20
> The current GDB code we have here uses num_condition_regs > 0 to =
discover if=20
> DVCs are supported, so a PPC_DEBUG_FEATURE constant for that is =
redundant=20
> IMHO.

That's fine, just want to make sure we are ok w/num_condition_regs =3D=3D =
0.

- k=

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> 
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> > 
> > GDB intends to support the following hardware debug features of BookE
> > processors:
> > 
> > 4 hardware breakpoints (IAC)
> > 2 hardware watchpoints (read, write and read-write) (DAC)
> > 2 value conditions for the hardware watchpoints (DVC)
> > 
> > For that, we need to extend ptrace so that GDB can query and set these
> > resources. Since we're extending, we're trying to create an interface
> > that's extendable and that covers both BookE and server processors, so
> > that GDB doesn't need to special-case each of them. We propose the
> > following 3 new ptrace requests described below.
> > 
> > There have been discussions of a generic hardware debug interface for the
> > kernel which would hopefully contemplate all the functionality below and
> > supersede it.  But we need something that works now, and which enables GDB
> > to be simpler and work with both Server and Embedded processors without
> > special cases.
> > 
> > 1. PTRACE_PPC_GETHWDEBUGINFO
> > 
> > Query for GDB to discover the hardware debug features. The main info to
> > be returned here is the minimum alignment for the hardware watchpoints.
> > BookE processors don't have restrictions here, but server processors have
> > an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> > adding special cases to GDB based on what it sees in AUXV.
> > 
> > Since we're at it, we added other useful info that the kernel can return to
> > GDB: this query will return the number of hardware breakpoints, hardware
> > watchpoints and whether it supports a range of addresses and a condition.
> > The query will fill the following structure provided by the requesting process:
> > 
> > struct ppc_debug_info {
> >       unit32_t version;
> >       unit32_t num_instruction_bps;
> >       unit32_t num_data_bps;
> >       unit32_t num_condition_regs;
> >       unit32_t data_bp_alignment;
> >       unit32_t sizeof_condition; /* size of the DVC register */
> >       uint64_t features; /* bitmask of the individual flags */
> > };
> > 
> > features will have bits indicating whether there is support for:
> > 
> > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> > #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> > #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
> 
> Is GDB smart enough to deal w/no condition_regs?  On some Book-E
> devices we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in the
> features?

I wasn't aware that the bookE devices had varying numbers of these
registers.  I guess I will have to make it a runtime option.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

On Mon, 2010-01-18 at 16:34 -0600, Dave Kleikamp wrote:
> On Thu, 2009-12-10 at 20:23 -0600, Kumar Gala wrote:

> > Is GDB smart enough to deal w/no condition_regs?  On some Book-E
> > devices we have 2 IACs, 2 DACs, and 0 DVCs.  Does it need to be in the
> > features?
> 
> I wasn't aware that the bookE devices had varying numbers of these
> registers.  I guess I will have to make it a runtime option.

Kumar,

Can you tell me which bookE processors have 2 IAC's, and which have no
DVC's?

I think we still may be able to make these compile-time options as long
no two cpus that run on the same binary kernel vary in the number of
registers.  Right now I know the 403 only has 2 IAC's, and I don't
intend to expose the DVC's for the 40x processors anyway.

If they don't need to be run-time configurable, I think it would be
cleaner to define the number of each type of register in CONFIG_ flags
and put the logic into the Kconfig files.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Kumar Gala]

On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:

> These patches implement an extention to the ptrace interface proposed =
by
> Thiago Bauermann and the the PowerPC gdb team.
>=20
> GDB intends to support the following hardware debug features of BookE
> processors:
>=20
> 4 hardware breakpoints (IAC)
> 2 hardware watchpoints (read, write and read-write) (DAC)
> 2 value conditions for the hardware watchpoints (DVC)
>=20
> For that, we need to extend ptrace so that GDB can query and set these
> resources. Since we're extending, we're trying to create an interface
> that's extendable and that covers both BookE and server processors, so
> that GDB doesn't need to special-case each of them. We propose the
> following 3 new ptrace requests described below.
>=20
> There have been discussions of a generic hardware debug interface for =
the
> kernel which would hopefully contemplate all the functionality below =
and
> supersede it.  But we need something that works now, and which enables =
GDB
> to be simpler and work with both Server and Embedded processors =
without
> special cases.
>=20
> 1. PTRACE_PPC_GETHWDEBUGINFO
>=20
> Query for GDB to discover the hardware debug features. The main info =
to
> be returned here is the minimum alignment for the hardware =
watchpoints.
> BookE processors don't have restrictions here, but server processors =
have
> an 8-byte alignment restriction for hardware watchpoints. We'd like to =
avoid
> adding special cases to GDB based on what it sees in AUXV.
>=20
> Since we're at it, we added other useful info that the kernel can =
return to
> GDB: this query will return the number of hardware breakpoints, =
hardware
> watchpoints and whether it supports a range of addresses and a =
condition.
> The query will fill the following structure provided by the requesting =
process:
>=20
> struct ppc_debug_info {
>       unit32_t version;
>       unit32_t num_instruction_bps;
>       unit32_t num_data_bps;
>       unit32_t num_condition_regs;
>       unit32_t data_bp_alignment;
>       unit32_t sizeof_condition; /* size of the DVC register */
>       uint64_t features; /* bitmask of the individual flags */
> };
>=20
> features will have bits indicating whether there is support for:
>=20
> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
>=20
> 2. PTRACE_SETHWDEBUG
>=20
> Sets a hardware breakpoint or watchpoint, according to the provided =
structure:
>=20
> struct ppc_hw_breakpoint {
>        uint32_t version;
> #define PPC_BREAKPOINT_TRIGGER_EXECUTE  0x1
> #define PPC_BREAKPOINT_TRIGGER_READ     0x2
> #define PPC_BREAKPOINT_TRIGGER_WRITE    0x4
>        uint32_t trigger_type;       /* only some combinations allowed =
*/
> #define PPC_BREAKPOINT_MODE_EXACT               0x0
> #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE     0x1
> #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE     0x2
> #define PPC_BREAKPOINT_MODE_MASK                0x3
>        uint32_t addr_mode;          /* address match mode */
>=20
> #define PPC_BREAKPOINT_CONDITION_NONE   0x0
> #define PPC_BREAKPOINT_CONDITION_AND    0x1
> #define PPC_BREAKPOINT_CONDITION_EXACT  0x1	/* different name for =
the same thing as above */
> #define PPC_BREAKPOINT_CONDITION_OR     0x2
> #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
> #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000	/* byte enable =
bits */
> #define PPC_BREAKPOINT_CONDITION_BE(n)  (1<<((n)+16))
>        uint32_t condition_mode;     /* break/watchpoint condition =
flags */
>=20
>        uint64_t addr;
>        uint64_t addr2;
>        uint64_t condition_value;
> };
>=20
> A request specifies one event, not necessarily just one register to be =
set.
> For instance, if the request is for a watchpoint with a condition, =
both the
> DAC and DVC registers will be set in the same request.
>=20
> With this GDB can ask for all kinds of hardware breakpoints and =
watchpoints
> that the BookE supports. COMEFROM breakpoints available in server =
processors
> are not contemplated, but that is out of the scope of this work.
>=20
> ptrace will return an integer (handle) uniquely identifying the =
breakpoint or
> watchpoint just created. This integer will be used in the =
PTRACE_DELHWDEBUG
> request to ask for its removal. Return -ENOSPC if the requested =
breakpoint
> can't be allocated on the registers.
>=20
> Some examples of using the structure to:
>=20
> - set a breakpoint in the first breakpoint register
>=20
>  p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>  p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_EXECUTE;
>  p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>  p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>  p.addr            =3D (uint64_t) address;
>  p.addr2           =3D 0;
>  p.condition_value =3D 0;
>=20
> - set a watchpoint which triggers on reads in the second watchpoint =
register
>=20
>  p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>  p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_READ;
>  p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>  p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>  p.addr            =3D (uint64_t) address;
>  p.addr2           =3D 0;
>  p.condition_value =3D 0;
>=20
> - set a watchpoint which triggers only with a specific value
>=20
>  p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>  p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_READ;
>  p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>  p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_AND | =
PPC_BREAKPOINT_CONDITION_BE_ALL;
>  p.addr            =3D (uint64_t) address;
>  p.addr2           =3D 0;
>  p.condition_value =3D (uint64_t) condition;
>=20
> - set a ranged hardware breakpoint
>=20
>  p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>  p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_EXECUTE;
>  p.addr_mode       =3D PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
>  p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>  p.addr            =3D (uint64_t) begin_range;
>  p.addr2           =3D (uint64_t) end_range;
>  p.condition_value =3D 0;
>=20
> 3. PTRACE_DELHWDEBUG
>=20
> Takes an integer which identifies an existing breakpoint or watchpoint
> (i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
> corresponding breakpoint or watchpoint..

This is a good write up.  We should have it as a commit message for the =
first patch.

- k

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
> 
> > These patches implement an extention to the ptrace interface proposed by
> > Thiago Bauermann and the the PowerPC gdb team.
> > 
> > GDB intends to support the following hardware debug features of BookE
> > processors:
> > 
> > 4 hardware breakpoints (IAC)
> > 2 hardware watchpoints (read, write and read-write) (DAC)
> > 2 value conditions for the hardware watchpoints (DVC)
> > 
> > For that, we need to extend ptrace so that GDB can query and set these
> > resources. Since we're extending, we're trying to create an interface
> > that's extendable and that covers both BookE and server processors, so
> > that GDB doesn't need to special-case each of them. We propose the
> > following 3 new ptrace requests described below.
> > 
> > There have been discussions of a generic hardware debug interface for the
> > kernel which would hopefully contemplate all the functionality below and
> > supersede it.  But we need something that works now, and which enables GDB
> > to be simpler and work with both Server and Embedded processors without
> > special cases.
> > 
> > 1. PTRACE_PPC_GETHWDEBUGINFO
> > 
> > Query for GDB to discover the hardware debug features. The main info to
> > be returned here is the minimum alignment for the hardware watchpoints.
> > BookE processors don't have restrictions here, but server processors have
> > an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
> > adding special cases to GDB based on what it sees in AUXV.
> > 
> > Since we're at it, we added other useful info that the kernel can return to
> > GDB: this query will return the number of hardware breakpoints, hardware
> > watchpoints and whether it supports a range of addresses and a condition.
> > The query will fill the following structure provided by the requesting process:
> > 
> > struct ppc_debug_info {
> >       unit32_t version;
> >       unit32_t num_instruction_bps;
> >       unit32_t num_data_bps;
> >       unit32_t num_condition_regs;
> >       unit32_t data_bp_alignment;
> >       unit32_t sizeof_condition; /* size of the DVC register */
> >       uint64_t features; /* bitmask of the individual flags */
> > };
> > 
> > features will have bits indicating whether there is support for:
> > 
> > #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
> > #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
> > #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
> > #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
> > 
> > 2. PTRACE_SETHWDEBUG
> > 
> > Sets a hardware breakpoint or watchpoint, according to the provided structure:
> > 
> > struct ppc_hw_breakpoint {
> >        uint32_t version;
> > #define PPC_BREAKPOINT_TRIGGER_EXECUTE  0x1
> > #define PPC_BREAKPOINT_TRIGGER_READ     0x2
> > #define PPC_BREAKPOINT_TRIGGER_WRITE    0x4
> >        uint32_t trigger_type;       /* only some combinations allowed */
> > #define PPC_BREAKPOINT_MODE_EXACT               0x0
> > #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE     0x1
> > #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE     0x2
> > #define PPC_BREAKPOINT_MODE_MASK                0x3
> >        uint32_t addr_mode;          /* address match mode */
> > 
> > #define PPC_BREAKPOINT_CONDITION_NONE   0x0
> > #define PPC_BREAKPOINT_CONDITION_AND    0x1
> > #define PPC_BREAKPOINT_CONDITION_EXACT  0x1	/* different name for the same thing as above */
> > #define PPC_BREAKPOINT_CONDITION_OR     0x2
> > #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
> > #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000	/* byte enable bits */
> > #define PPC_BREAKPOINT_CONDITION_BE(n)  (1<<((n)+16))
> >        uint32_t condition_mode;     /* break/watchpoint condition flags */
> > 
> >        uint64_t addr;
> >        uint64_t addr2;
> >        uint64_t condition_value;
> > };
> > 
> > A request specifies one event, not necessarily just one register to be set.
> > For instance, if the request is for a watchpoint with a condition, both the
> > DAC and DVC registers will be set in the same request.
> > 
> > With this GDB can ask for all kinds of hardware breakpoints and watchpoints
> > that the BookE supports. COMEFROM breakpoints available in server processors
> > are not contemplated, but that is out of the scope of this work.
> > 
> > ptrace will return an integer (handle) uniquely identifying the breakpoint or
> > watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
> > request to ask for its removal. Return -ENOSPC if the requested breakpoint
> > can't be allocated on the registers.
> > 
> > Some examples of using the structure to:
> > 
> > - set a breakpoint in the first breakpoint register
> > 
> >  p.version         = PPC_DEBUG_CURRENT_VERSION;
> >  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
> >  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
> >  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
> >  p.addr            = (uint64_t) address;
> >  p.addr2           = 0;
> >  p.condition_value = 0;
> > 
> > - set a watchpoint which triggers on reads in the second watchpoint register
> > 
> >  p.version         = PPC_DEBUG_CURRENT_VERSION;
> >  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
> >  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
> >  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
> >  p.addr            = (uint64_t) address;
> >  p.addr2           = 0;
> >  p.condition_value = 0;
> > 
> > - set a watchpoint which triggers only with a specific value
> > 
> >  p.version         = PPC_DEBUG_CURRENT_VERSION;
> >  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_READ;
> >  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
> >  p.condition_mode  = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
> >  p.addr            = (uint64_t) address;
> >  p.addr2           = 0;
> >  p.condition_value = (uint64_t) condition;
> > 
> > - set a ranged hardware breakpoint
> > 
> >  p.version         = PPC_DEBUG_CURRENT_VERSION;
> >  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_EXECUTE;
> >  p.addr_mode       = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
> >  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
> >  p.addr            = (uint64_t) begin_range;
> >  p.addr2           = (uint64_t) end_range;
> >  p.condition_value = 0;
> > 
> > 3. PTRACE_DELHWDEBUG
> > 
> > Takes an integer which identifies an existing breakpoint or watchpoint
> > (i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
> > corresponding breakpoint or watchpoint..
> 
> This is a good write up.  We should have it as a commit message for the first patch.

I have to give credit to Thiago for this.

Would it be worth adding to Documentation/powerpc/ ?
-- 
David Kleikamp
IBM Linux Technology Center

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Kumar Gala]

On Dec 10, 2009, at 8:29 PM, Dave Kleikamp wrote:

> On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
>> On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:
>>=20
>>> These patches implement an extention to the ptrace interface =
proposed by
>>> Thiago Bauermann and the the PowerPC gdb team.
>>>=20
>>> GDB intends to support the following hardware debug features of =
BookE
>>> processors:
>>>=20
>>> 4 hardware breakpoints (IAC)
>>> 2 hardware watchpoints (read, write and read-write) (DAC)
>>> 2 value conditions for the hardware watchpoints (DVC)
>>>=20
>>> For that, we need to extend ptrace so that GDB can query and set =
these
>>> resources. Since we're extending, we're trying to create an =
interface
>>> that's extendable and that covers both BookE and server processors, =
so
>>> that GDB doesn't need to special-case each of them. We propose the
>>> following 3 new ptrace requests described below.
>>>=20
>>> There have been discussions of a generic hardware debug interface =
for the
>>> kernel which would hopefully contemplate all the functionality below =
and
>>> supersede it.  But we need something that works now, and which =
enables GDB
>>> to be simpler and work with both Server and Embedded processors =
without
>>> special cases.
>>>=20
>>> 1. PTRACE_PPC_GETHWDEBUGINFO
>>>=20
>>> Query for GDB to discover the hardware debug features. The main info =
to
>>> be returned here is the minimum alignment for the hardware =
watchpoints.
>>> BookE processors don't have restrictions here, but server processors =
have
>>> an 8-byte alignment restriction for hardware watchpoints. We'd like =
to avoid
>>> adding special cases to GDB based on what it sees in AUXV.
>>>=20
>>> Since we're at it, we added other useful info that the kernel can =
return to
>>> GDB: this query will return the number of hardware breakpoints, =
hardware
>>> watchpoints and whether it supports a range of addresses and a =
condition.
>>> The query will fill the following structure provided by the =
requesting process:
>>>=20
>>> struct ppc_debug_info {
>>>      unit32_t version;
>>>      unit32_t num_instruction_bps;
>>>      unit32_t num_data_bps;
>>>      unit32_t num_condition_regs;
>>>      unit32_t data_bp_alignment;
>>>      unit32_t sizeof_condition; /* size of the DVC register */
>>>      uint64_t features; /* bitmask of the individual flags */
>>> };
>>>=20
>>> features will have bits indicating whether there is support for:
>>>=20
>>> #define PPC_DEBUG_FEATURE_INSN_BP_RANGE		0x1
>>> #define PPC_DEBUG_FEATURE_INSN_BP_MASK		0x2
>>> #define PPC_DEBUG_FEATURE_DATA_BP_RANGE		0x4
>>> #define PPC_DEBUG_FEATURE_DATA_BP_MASK		0x8
>>>=20
>>> 2. PTRACE_SETHWDEBUG
>>>=20
>>> Sets a hardware breakpoint or watchpoint, according to the provided =
structure:
>>>=20
>>> struct ppc_hw_breakpoint {
>>>       uint32_t version;
>>> #define PPC_BREAKPOINT_TRIGGER_EXECUTE  0x1
>>> #define PPC_BREAKPOINT_TRIGGER_READ     0x2
>>> #define PPC_BREAKPOINT_TRIGGER_WRITE    0x4
>>>       uint32_t trigger_type;       /* only some combinations allowed =
*/
>>> #define PPC_BREAKPOINT_MODE_EXACT               0x0
>>> #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE     0x1
>>> #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE     0x2
>>> #define PPC_BREAKPOINT_MODE_MASK                0x3
>>>       uint32_t addr_mode;          /* address match mode */
>>>=20
>>> #define PPC_BREAKPOINT_CONDITION_NONE   0x0
>>> #define PPC_BREAKPOINT_CONDITION_AND    0x1
>>> #define PPC_BREAKPOINT_CONDITION_EXACT  0x1	/* different name for =
the same thing as above */
>>> #define PPC_BREAKPOINT_CONDITION_OR     0x2
>>> #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
>>> #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000	/* byte enable =
bits */
>>> #define PPC_BREAKPOINT_CONDITION_BE(n)  (1<<((n)+16))
>>>       uint32_t condition_mode;     /* break/watchpoint condition =
flags */
>>>=20
>>>       uint64_t addr;
>>>       uint64_t addr2;
>>>       uint64_t condition_value;
>>> };
>>>=20
>>> A request specifies one event, not necessarily just one register to =
be set.
>>> For instance, if the request is for a watchpoint with a condition, =
both the
>>> DAC and DVC registers will be set in the same request.
>>>=20
>>> With this GDB can ask for all kinds of hardware breakpoints and =
watchpoints
>>> that the BookE supports. COMEFROM breakpoints available in server =
processors
>>> are not contemplated, but that is out of the scope of this work.
>>>=20
>>> ptrace will return an integer (handle) uniquely identifying the =
breakpoint or
>>> watchpoint just created. This integer will be used in the =
PTRACE_DELHWDEBUG
>>> request to ask for its removal. Return -ENOSPC if the requested =
breakpoint
>>> can't be allocated on the registers.
>>>=20
>>> Some examples of using the structure to:
>>>=20
>>> - set a breakpoint in the first breakpoint register
>>>=20
>>> p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>>> p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_EXECUTE;
>>> p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>>> p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>>> p.addr            =3D (uint64_t) address;
>>> p.addr2           =3D 0;
>>> p.condition_value =3D 0;
>>>=20
>>> - set a watchpoint which triggers on reads in the second watchpoint =
register
>>>=20
>>> p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>>> p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_READ;
>>> p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>>> p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>>> p.addr            =3D (uint64_t) address;
>>> p.addr2           =3D 0;
>>> p.condition_value =3D 0;
>>>=20
>>> - set a watchpoint which triggers only with a specific value
>>>=20
>>> p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>>> p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_READ;
>>> p.addr_mode       =3D PPC_BREAKPOINT_MODE_EXACT;
>>> p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_AND | =
PPC_BREAKPOINT_CONDITION_BE_ALL;
>>> p.addr            =3D (uint64_t) address;
>>> p.addr2           =3D 0;
>>> p.condition_value =3D (uint64_t) condition;
>>>=20
>>> - set a ranged hardware breakpoint
>>>=20
>>> p.version         =3D PPC_DEBUG_CURRENT_VERSION;
>>> p.trigger_type    =3D PPC_BREAKPOINT_TRIGGER_EXECUTE;
>>> p.addr_mode       =3D PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
>>> p.condition_mode  =3D PPC_BREAKPOINT_CONDITION_NONE;
>>> p.addr            =3D (uint64_t) begin_range;
>>> p.addr2           =3D (uint64_t) end_range;
>>> p.condition_value =3D 0;
>>>=20
>>> 3. PTRACE_DELHWDEBUG
>>>=20
>>> Takes an integer which identifies an existing breakpoint or =
watchpoint
>>> (i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
>>> corresponding breakpoint or watchpoint..
>>=20
>> This is a good write up.  We should have it as a commit message for =
the first patch.
>=20
> I have to give credit to Thiago for this.
>=20
> Would it be worth adding to Documentation/powerpc/ ?

That would also work.

- k=

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Benjamin Herrenschmidt]

On Thu, 2009-12-10 at 20:24 -0600, Kumar Gala wrote:
> This is a good write up.  We should have it as a commit message for
> the first patch.

No, that should go into Documentation/powerpc/

Cheers,
Ben.

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Kumar Gala]

On Dec 10, 2009, at 9:57 AM, Dave Kleikamp wrote:

> These patches implement an extention to the ptrace interface proposed =
by
> Thiago Bauermann and the the PowerPC gdb team.
>=20
> GDB intends to support the following hardware debug features of BookE
> processors:
>=20
> 4 hardware breakpoints (IAC)
> 2 hardware watchpoints (read, write and read-write) (DAC)
> 2 value conditions for the hardware watchpoints (DVC)
>=20
> For that, we need to extend ptrace so that GDB can query and set these
> resources. Since we're extending, we're trying to create an interface
> that's extendable and that covers both BookE and server processors, so
> that GDB doesn't need to special-case each of them. We propose the
> following 3 new ptrace requests described below.
>=20
> There have been discussions of a generic hardware debug interface for =
the
> kernel which would hopefully contemplate all the functionality below =
and
> supersede it.  But we need something that works now, and which enables =
GDB
> to be simpler and work with both Server and Embedded processors =
without
> special cases.

What do we do in EDM mode?  We need a flag somewhere to determine if HW =
supports conveying DBCR0[EDM] and if it does which of the ptrace calls =
fails?

- k=

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

[Dave Kleikamp]

On Thu, 2009-12-10 at 20:45 -0600, Kumar Gala wrote:

> What do we do in EDM mode?  We need a flag somewhere to determine if
> HW supports conveying DBCR0[EDM] and if it does which of the ptrace
> calls fails?

I really don't have a good answer to this.  I'm open to any and all
advice.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center