watch exception only for kseg0 addresses..?

watch exception only for kseg0 addresses..?

[atul srivastava]

Hello,

I am trying to set a watch exception in (IDT RC32334) my debugging 
execise
In arch/mips/lib/watch.S says "curremtly available only for KSEG0 
address"

which is evident by following assembly..
                 LEAF(__watch_set)
                 li      t0,0x80000000
                 subu    a0,t0
                 ori     a0,7
                 xori    a0,7
                 or      a0,a1
                 mtc0    a0,CP0_WATCHLO
                 .......

it is loading the physical address of KSEG0 addresses in CP0 
watchpoint register.

in change history of this file i am able to see  KSEG0 restriction 
removed only for arch/mips64/lib/watch.S...

while my manual is not specific about KSEG0 , can i safely use it 
for all addresses ,offcourse then above assembly has to be 
modified appropiately for addresses of different regions..

Best Regards.
Ashish

Re: watch exception only for kseg0 addresses..?

[Ralf Baechle]

On Mon, Nov 25, 2002 at 07:52:38AM -0000, atul srivastava wrote:

>                  LEAF(__watch_set)
>                  li      t0,0x80000000
>                  subu    a0,t0
>                  ori     a0,7
>                  xori    a0,7
>                  or      a0,a1
>                  mtc0    a0,CP0_WATCHLO
>                  .......
> 
> it is loading the physical address of KSEG0 addresses in CP0 
> watchpoint register.

Additional problem - I know of at least one CPU on which the watch register
does not work for KSEG0 but only for TLB mapped registers.  That CPU
doesn't document this behaviour btw.

> in change history of this file i am able to see  KSEG0 restriction 
> removed only for arch/mips64/lib/watch.S...

The hw takes physical addresses, so using a a virtual address as argument
for __watch_set seemed to be stupid anyway.  The hw takes a physical
address and the conversion is best done in C anyway.

> while my manual is not specific about KSEG0 , can i safely use it 
> for all addresses ,offcourse then above assembly has to be 
> modified appropiately for addresses of different regions..

The whole watch stuff in the the kernel is pretty much an ad-hoc API
which I did create to debug a stack overflow.  I'm sure if you're
going to use it you'll find problems.  For userspace for example you'd
have to switch the watch register when switching the MMU context so
each process gets it's own virtual watch register.  Beyond that there
are at least two different formats of watch registers implemented in
actual silicon, the original R4000-style and the MIPS32/MIPS64 style
watch registers and the kernel's watch code only know the R4000 style
one.  So check your CPU's manual ...

  Ralf

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Mon, 25 Nov 2002, Ralf Baechle wrote:

> The whole watch stuff in the the kernel is pretty much an ad-hoc API
> which I did create to debug a stack overflow.  I'm sure if you're
> going to use it you'll find problems.  For userspace for example you'd
> have to switch the watch register when switching the MMU context so
> each process gets it's own virtual watch register.  Beyond that there
> are at least two different formats of watch registers implemented in
> actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> watch registers and the kernel's watch code only know the R4000 style
> one.  So check your CPU's manual ...

 I think the best use of the watch exception would be making it available
to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
support (e.g. for gdb).  Hardware support is absolutely necessary for
watching read accesses and much beneficial for write ones (otherwise gdb
single-steps code which sucks performace-wise).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Ralf Baechle]

On Mon, Nov 25, 2002 at 12:55:11PM +0100, Maciej W. Rozycki wrote:

> > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > which I did create to debug a stack overflow.  I'm sure if you're
> > going to use it you'll find problems.  For userspace for example you'd
> > have to switch the watch register when switching the MMU context so
> > each process gets it's own virtual watch register.  Beyond that there
> > are at least two different formats of watch registers implemented in
> > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > watch registers and the kernel's watch code only know the R4000 style
> > one.  So check your CPU's manual ...
> 
>  I think the best use of the watch exception would be making it available
> to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> support (e.g. for gdb).  Hardware support is absolutely necessary for
> watching read accesses and much beneficial for write ones (otherwise gdb
> single-steps code which sucks performace-wise).

Agreed.  And because such an extension would be fully backward compatible
introduction is no problem.  So time to come up with a reasonable API.
MIPS32 / MIPS64 extend the R4000's watch capabilities significantly,
something we don't want to ignore.

  Ralf

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Mon, Nov 25, 2002 at 12:55:11PM +0100, Maciej W. Rozycki wrote:
> On Mon, 25 Nov 2002, Ralf Baechle wrote:
> 
> > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > which I did create to debug a stack overflow.  I'm sure if you're
> > going to use it you'll find problems.  For userspace for example you'd
> > have to switch the watch register when switching the MMU context so
> > each process gets it's own virtual watch register.  Beyond that there
> > are at least two different formats of watch registers implemented in
> > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > watch registers and the kernel's watch code only know the R4000 style
> > one.  So check your CPU's manual ...
> 
>  I think the best use of the watch exception would be making it available
> to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> support (e.g. for gdb).  Hardware support is absolutely necessary for
> watching read accesses and much beneficial for write ones (otherwise gdb
> single-steps code which sucks performace-wise).

(Although that isn't necessary; page-protection watchpoints are on my
TODO for next year.  They aren't quite as efficient as hardware
watchpoints but they don't require hardware support either, just an
MMU.)

Heck, you can even do read watchpoints that way.

In any case, yes, the thing to do is choose an API for these and expose
them via ptrace; not necessarily in PEEKUSER though.  There's no cost
to adding new PTRACE_* ops.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Ralf Baechle]

On Mon, Nov 25, 2002 at 09:40:59AM -0500, Daniel Jacobowitz wrote:

> > > The whole watch stuff in the the kernel is pretty much an ad-hoc API
> > > which I did create to debug a stack overflow.  I'm sure if you're
> > > going to use it you'll find problems.  For userspace for example you'd
> > > have to switch the watch register when switching the MMU context so
> > > each process gets it's own virtual watch register.  Beyond that there
> > > are at least two different formats of watch registers implemented in
> > > actual silicon, the original R4000-style and the MIPS32/MIPS64 style
> > > watch registers and the kernel's watch code only know the R4000 style
> > > one.  So check your CPU's manual ...
> > 
> >  I think the best use of the watch exception would be making it available
> > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> > support (e.g. for gdb).  Hardware support is absolutely necessary for
> > watching read accesses and much beneficial for write ones (otherwise gdb
> > single-steps code which sucks performace-wise).
> 
> (Although that isn't necessary; page-protection watchpoints are on my
> TODO for next year.  They aren't quite as efficient as hardware
> watchpoints but they don't require hardware support either, just an
> MMU.)
> 
> Heck, you can even do read watchpoints that way.
> 
> In any case, yes, the thing to do is choose an API for these and expose
> them via ptrace; not necessarily in PEEKUSER though.  There's no cost
> to adding new PTRACE_* ops.

I assume you got and R4000 manual and the MIPS64 spec.   R4000 implements
matching a physical address with a granularity of 8 bytes for load and
store operations.

MIPS64 extends that to also support instruction address matches; the
granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
matching and a global bit can be used for matching.  A MIPS64 CPU can
support anywhere from 0 to 4 such watch registers.

The global bit stuff would only be useful for in-kernel use, I think.  The
ASID thing could be used to implement watchpoints for an entire process, not
just per thread though I doubt there is much use for something like that.

So how would a prefered ptrace(2) API for hardware watchpoints look like?

  Ralf

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Mon, 25 Nov 2002, Ralf Baechle wrote:

> MIPS64 extends that to also support instruction address matches; the
> granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
> matching and a global bit can be used for matching.  A MIPS64 CPU can
> support anywhere from 0 to 4 such watch registers.

 Actually up to eight -- for all dmfc0/dmtc0 3-bit "sel" values, if I read
it correctly.

> The global bit stuff would only be useful for in-kernel use, I think.  The
> ASID thing could be used to implement watchpoints for an entire process, not
> just per thread though I doubt there is much use for something like that.

 Well, there are two options only -- either use global matching or ASID
matching.  What else would you expect?  Do you mean lazy vs immediate
switching? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Ralf Baechle]

On Mon, Nov 25, 2002 at 04:47:33PM +0100, Maciej W. Rozycki wrote:

> > MIPS64 extends that to also support instruction address matches; the
> > granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
> > matching and a global bit can be used for matching.  A MIPS64 CPU can
> > support anywhere from 0 to 4 such watch registers.
> 
>  Actually up to eight -- for all dmfc0/dmtc0 3-bit "sel" values, if I read
> it correctly.

Correct but I don't know of any CPU that actually uses more than 4 of the
possible 8 sets atm.  So we're both right :)

> > The global bit stuff would only be useful for in-kernel use, I think.  The
> > ASID thing could be used to implement watchpoints for an entire process, not
> > just per thread though I doubt there is much use for something like that.
> 
>  Well, there are two options only -- either use global matching or ASID
> matching.  What else would you expect?  Do you mean lazy vs immediate
> switching? 

Basically there would be two possibilities, associate the debugging state
of a process with it's thread_struct or with it's mm_struct.  The latter
would have a little less impact on the context switching performance,
the first be a bit more flexible.

  Ralf

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Wed, Dec 04, 2002 at 01:37:13AM +0100, Ralf Baechle wrote:
> On Mon, Nov 25, 2002 at 04:47:33PM +0100, Maciej W. Rozycki wrote:
> 
> > > MIPS64 extends that to also support instruction address matches; the
> > > granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
> > > matching and a global bit can be used for matching.  A MIPS64 CPU can
> > > support anywhere from 0 to 4 such watch registers.
> > 
> >  Actually up to eight -- for all dmfc0/dmtc0 3-bit "sel" values, if I read
> > it correctly.
> 
> Correct but I don't know of any CPU that actually uses more than 4 of the
> possible 8 sets atm.  So we're both right :)
> 
> > > The global bit stuff would only be useful for in-kernel use, I think.  The
> > > ASID thing could be used to implement watchpoints for an entire process, not
> > > just per thread though I doubt there is much use for something like that.
> > 
> >  Well, there are two options only -- either use global matching or ASID
> > matching.  What else would you expect?  Do you mean lazy vs immediate
> > switching? 
> 
> Basically there would be two possibilities, associate the debugging state
> of a process with it's thread_struct or with it's mm_struct.  The latter
> would have a little less impact on the context switching performance,
> the first be a bit more flexible.

Thread_struct, please.  Just because two processes have the same
mm_struct doesn't mean that we want watchpoints to trigger in both of
them, unless specifically requested.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Wed, 4 Dec 2002, Ralf Baechle wrote:

> Correct but I don't know of any CPU that actually uses more than 4 of the
> possible 8 sets atm.  So we're both right :)

 Well, software needs to be prepared to handle eight ones.  Actually it's
easy to handle any number. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Mon, 25 Nov 2002, Daniel Jacobowitz wrote:

> >  I think the best use of the watch exception would be making it available
> > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> > support (e.g. for gdb).  Hardware support is absolutely necessary for
> > watching read accesses and much beneficial for write ones (otherwise gdb
> > single-steps code which sucks performace-wise).
> 
> (Although that isn't necessary; page-protection watchpoints are on my
> TODO for next year.  They aren't quite as efficient as hardware
> watchpoints but they don't require hardware support either, just an
> MMU.)

 As a fallback the approach is just fine, but doesn't is suck
performance-wise for watchpoints at the stack?  It certainly sucks for
instruction fetches.  While gdb doesn't seem to use hardware breakpoints
as they are only really necessary for ROMs, other software may want to
(well, gdb too, one day). 

> In any case, yes, the thing to do is choose an API for these and expose
> them via ptrace; not necessarily in PEEKUSER though.  There's no cost
> to adding new PTRACE_* ops.

 Sure, as long as common sense is applied.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Mon, Nov 25, 2002 at 04:30:13PM +0100, Maciej W. Rozycki wrote:
> On Mon, 25 Nov 2002, Daniel Jacobowitz wrote:
> 
> > >  I think the best use of the watch exception would be making it available
> > > to userland via PTRACE_PEEKUSR and PTRACE_POKEUSR for hardware watchpoint
> > > support (e.g. for gdb).  Hardware support is absolutely necessary for
> > > watching read accesses and much beneficial for write ones (otherwise gdb
> > > single-steps code which sucks performace-wise).
> > 
> > (Although that isn't necessary; page-protection watchpoints are on my
> > TODO for next year.  They aren't quite as efficient as hardware
> > watchpoints but they don't require hardware support either, just an
> > MMU.)
> 
>  As a fallback the approach is just fine, but doesn't is suck
> performance-wise for watchpoints at the stack?  It certainly sucks for
> instruction fetches.  While gdb doesn't seem to use hardware breakpoints
> as they are only really necessary for ROMs, other software may want to
> (well, gdb too, one day). 

Page-protection watchpoints on the stack do bite for performance, yes. 
Most watched variables are not on the stack, though.  People tend to
watch globals.


On Mon, Nov 25, 2002 at 04:08:00PM +0100, Ralf Baechle wrote:
> I assume you got and R4000 manual and the MIPS64 spec.   R4000 implements
> matching a physical address with a granularity of 8 bytes for load and
> store operations.

Not handy.

> MIPS64 extends that to also support instruction address matches; the
> granularity can be set anywhere from 8 bytes to 4kB; in addition ASID
> matching and a global bit can be used for matching.  A MIPS64 CPU can
> support anywhere from 0 to 4 such watch registers.
> 
> The global bit stuff would only be useful for in-kernel use, I think.  The
> ASID thing could be used to implement watchpoints for an entire process, not
> just per thread though I doubt there is much use for something like that.
> 
> So how would a prefered ptrace(2) API for hardware watchpoints look like?

Well, it would be nice to have at least:
  - query total number
  - query the granularity, or at least query whether or not the
    granularity is settable
  - Set and remove watchpoints.

Off the top of my head:
PTRACE_MIPS_WATCHPOINT_INFO
struct mips_watchpoint_info {
  u32 num_avail;
  u32 max_size;
};

PTRACE_MIPS_WATCHPOINT_SET
struct mips_watchpoint_set {
  u32 index;
  u32 size;
  s64 address;
};

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Tue, 3 Dec 2002, Daniel Jacobowitz wrote:

> >  As a fallback the approach is just fine, but doesn't is suck
> > performance-wise for watchpoints at the stack?  It certainly sucks for
> > instruction fetches.  While gdb doesn't seem to use hardware breakpoints
> > as they are only really necessary for ROMs, other software may want to
> > (well, gdb too, one day). 
> 
> Page-protection watchpoints on the stack do bite for performance, yes. 
> Most watched variables are not on the stack, though.  People tend to
> watch globals.

 Well, so far I've almost exclusively watched the stack, sometimes
malloc()ed areas, to track down out of bound corruption.  It's really
useful when a program crashes with a SIGSEGV when returning from a
function call or when calling free() with a legal pointer.  Watching
globals has not been really useful for me so far -- they are rarely used
in the first place and you know where they can get modified, so you can
set ordinary breakpoints in contexts of interest. 

> On Mon, Nov 25, 2002 at 04:08:00PM +0100, Ralf Baechle wrote:
> > I assume you got and R4000 manual and the MIPS64 spec.   R4000 implements
> > matching a physical address with a granularity of 8 bytes for load and
> > store operations.
> 
> Not handy.

 Still better than nothing.  Userland doesn't need to care of the
underlying implementation anyway.  You simply have a single watchpoint
available.  The kernel needs to take care when entering and exiting
userland.

> > So how would a prefered ptrace(2) API for hardware watchpoints look like?
> 
> Well, it would be nice to have at least:
>   - query total number
>   - query the granularity, or at least query whether or not the
>     granularity is settable
>   - Set and remove watchpoints.
> 
> Off the top of my head:
> PTRACE_MIPS_WATCHPOINT_INFO
> struct mips_watchpoint_info {
>   u32 num_avail;
>   u32 max_size;
> };

 The information may be provided when reading the registers.

> PTRACE_MIPS_WATCHPOINT_SET
> struct mips_watchpoint_set {
>   u32 index;
>   u32 size;
>   s64 address;
> };

 How about a KISS approach:

typedef struct {
	s64 address;
	u64 mask;
	u64 access;
} mips_watchpoint;

typedef struct {
	s32 api_version;
	s32 nr_watchpoints;
	mips_watchpoint watchpoints[0];
} mips_watchpoint_set;

Then PTRACE_MIPS_WATCHPOINT_GET is used to retrieve current settings,
PTRACE_MIPS_WATCHPOINT_SET is used to alter them.  More details:

PTRACE_MIPS_WATCHPOINT_SET:

Input:

- api_version has to match the version implemented, currently 0,

- nr_watchpoints specifies the number of watchpoint descriptions
  following, >= 0,

- for each watchpoints entry i, (i = 0; i < nr_watchpoints; i++):

  - address specifies the virtual address covered -- properly
    sign-extended for the 32-bit kernel),

  - mask specifies the mask to use against the address -- don't care bits
    set to one,

  - access specifies the access type; currently read, write and exec are
    specified -- we may follow the MIPS32/64 ISA definition.

Output:

- error code: a failure if a protection violation happens when reading
  mips_watchpoint_set, otherwise success.

PTRACE_MIPS_WATCHPOINT_GET:

Input:

- api_version set to the version expected, currently 0, = api_version_i,

- nr_watchpoints specifies the maximum number of watchpoint descriptions
  expected, >= 0, = nr_watchpoints_i

Output:

- error code: a failure if a protection violation happens when writing
  mips_watchpoint_set, otherwise success,

- api_version set to the version supported, currently 0, = api_version_o,

- if (api_version_i == api_version_o):

  - nr_watchpoints set to the number of watchpoints supported, >= 0, =
    nr_watchpoints_o,

  - for each watchpoints entry i, (i = 0; i < min(nr_watchpoints_i,
    nr_watchpoints_o; i++):

    - address set to the value preset for the watchpoint, as obtained
      from hardware,

    - mask set to the value preset for the watchpoint, as obtained from
      hardware,

    - access set to the value preset for the watchpoint, as obtained from
      hardware.

 I think such an interface covers all the functionality we care of now,
including implementation variations (R4000 vs R4650 vs MIPS32/64), and
provides for cheap future expansion.  Additionally thread-global
watchpoints may be handled by adding a bit to the access member if needed. 

 What do you think?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Wed, Dec 04, 2002 at 04:45:38PM +0100, Maciej W. Rozycki wrote:
> On Tue, 3 Dec 2002, Daniel Jacobowitz wrote:
> 
> > >  As a fallback the approach is just fine, but doesn't is suck
> > > performance-wise for watchpoints at the stack?  It certainly sucks for
> > > instruction fetches.  While gdb doesn't seem to use hardware breakpoints
> > > as they are only really necessary for ROMs, other software may want to
> > > (well, gdb too, one day). 
> > 
> > Page-protection watchpoints on the stack do bite for performance, yes. 
> > Most watched variables are not on the stack, though.  People tend to
> > watch globals.
> 
>  Well, so far I've almost exclusively watched the stack, sometimes
> malloc()ed areas, to track down out of bound corruption.  It's really
> useful when a program crashes with a SIGSEGV when returning from a
> function call or when calling free() with a legal pointer.  Watching
> globals has not been really useful for me so far -- they are rarely used
> in the first place and you know where they can get modified, so you can
> set ordinary breakpoints in contexts of interest. 

Whereas I'm usually tracking global or heap variables whose value is
getting set to something peculiar.  Interesting.

> 
> > On Mon, Nov 25, 2002 at 04:08:00PM +0100, Ralf Baechle wrote:
> > > I assume you got and R4000 manual and the MIPS64 spec.   R4000 implements
> > > matching a physical address with a granularity of 8 bytes for load and
> > > store operations.
> > 
> > Not handy.
> 
>  Still better than nothing.

Sorry, by "not handy" I meant I didn't have the manuals available :)

>  Userland doesn't need to care of the
> underlying implementation anyway.  You simply have a single watchpoint
> available.  The kernel needs to take care when entering and exiting
> userland.
> 
> > > So how would a prefered ptrace(2) API for hardware watchpoints look like?
> > 
> > Well, it would be nice to have at least:
> >   - query total number
> >   - query the granularity, or at least query whether or not the
> >     granularity is settable
> >   - Set and remove watchpoints.
> > 
> > Off the top of my head:
> > PTRACE_MIPS_WATCHPOINT_INFO
> > struct mips_watchpoint_info {
> >   u32 num_avail;
> >   u32 max_size;
> > };
> 
>  The information may be provided when reading the registers.
> 
> > PTRACE_MIPS_WATCHPOINT_SET
> > struct mips_watchpoint_set {
> >   u32 index;
> >   u32 size;
> >   s64 address;
> > };
> 
>  How about a KISS approach:
> 
> typedef struct {
> 	s64 address;
> 	u64 mask;
> 	u64 access;
> } mips_watchpoint;
> 
> typedef struct {
> 	s32 api_version;
> 	s32 nr_watchpoints;
> 	mips_watchpoint watchpoints[0];
> } mips_watchpoint_set;
> 
> Then PTRACE_MIPS_WATCHPOINT_GET is used to retrieve current settings,
> PTRACE_MIPS_WATCHPOINT_SET is used to alter them.  More details:

>  What do you think?

You don't reveal to userland what size watchpoints are available - i.e.
how large a watchpoint can be.  Does the mask match the hardware
implementation, and what are the restrictions on it?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Wed, 4 Dec 2002, Daniel Jacobowitz wrote:

> Sorry, by "not handy" I meant I didn't have the manuals available :)

 'http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf' or see under
"Publications"/"R4000...".  There are other sources of the book available,
e.g. somewhere within SGI web pages.  R10k implements a single watchpoint
this way, too. 

> >  What do you think?
> 
> You don't reveal to userland what size watchpoints are available - i.e.
> how large a watchpoint can be.  Does the mask match the hardware
> implementation, and what are the restrictions on it?

 For that you set up a disabled watchpoint with a mask set to all ones (or
the range you are interested in).  Then when you retrieve it, you may see
which bits stayed at ones.  Similarly you may check for hardwired
don't-cares by using a mask with all zeroes.  The mask may differ for each
watchpoint, e.g. for R4650 it's different for IWatch and DWatch, so you
really want to have a per-watchpoint setting.  Also the MIPS32/64 ISA
specification implies a mask need not be contiguous. 

 Similarly you may check for access types permitted, by enabling all of
them (or ones you are interested in) and seeing which ones remained
enabled.  Per-watchpoint, again. 

 I'd prefer not to overdesign the API leaving as much information as
possible passed as is.  This way userland gets more control over what's
available.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Wed, Dec 04, 2002 at 06:54:02PM +0100, Maciej W. Rozycki wrote:
> On Wed, 4 Dec 2002, Daniel Jacobowitz wrote:
> 
> > Sorry, by "not handy" I meant I didn't have the manuals available :)
> 
>  'http://www.mips.com/Documentation/R4400_Uman_book_Ed2.pdf' or see under
> "Publications"/"R4000...".  There are other sources of the book available,
> e.g. somewhere within SGI web pages.  R10k implements a single watchpoint
> this way, too. 
> 
> > >  What do you think?
> > 
> > You don't reveal to userland what size watchpoints are available - i.e.
> > how large a watchpoint can be.  Does the mask match the hardware
> > implementation, and what are the restrictions on it?
> 
>  For that you set up a disabled watchpoint with a mask set to all ones (or
> the range you are interested in).  Then when you retrieve it, you may see
> which bits stayed at ones.  Similarly you may check for hardwired
> don't-cares by using a mask with all zeroes.  The mask may differ for each
> watchpoint, e.g. for R4650 it's different for IWatch and DWatch, so you
> really want to have a per-watchpoint setting.  Also the MIPS32/64 ISA
> specification implies a mask need not be contiguous. 
> 
>  Similarly you may check for access types permitted, by enabling all of
> them (or ones you are interested in) and seeing which ones remained
> enabled.  Per-watchpoint, again. 
> 
>  I'd prefer not to overdesign the API leaving as much information as
> possible passed as is.  This way userland gets more control over what's
> available.

That way we expose more of the hardware to userland; and the thing
that's most important to me is that GDB not have to know if it's on a
MIPS32 or an R4650 when determining how watchpoints work. 
IWatch/DWatch are two particular watchpoints or distinguished by access
type?  I.E. what would GDB need to know to know which it is setting?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Wed, 11 Dec 2002, Daniel Jacobowitz wrote:

> That way we expose more of the hardware to userland; and the thing
> that's most important to me is that GDB not have to know if it's on a
> MIPS32 or an R4650 when determining how watchpoints work. 
> IWatch/DWatch are two particular watchpoints or distinguished by access
> type?  I.E. what would GDB need to know to know which it is setting?

 The watchpoints would always be interfaced the same way, regardless of
the underlying implementation, of course.  For the IWatch/DWatch, I'd
assign their numbers somehow (e.g. IWatch is watchpoint #0 and DWatch is
#1, following the sequence used for their CP0 register numbers).  A user
such as GDB would have to determine the capabilities of all watchpoints as
I described and would discover that watchpoint #0 only accepts instruction
fetch events and watchpoint #1 only accepts data read/write ones.

 This way we can accept an arbitrary underlying implementation.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz]

On Wed, Dec 11, 2002 at 06:38:51PM +0100, Maciej W. Rozycki wrote:
> On Wed, 11 Dec 2002, Daniel Jacobowitz wrote:
> 
> > That way we expose more of the hardware to userland; and the thing
> > that's most important to me is that GDB not have to know if it's on a
> > MIPS32 or an R4650 when determining how watchpoints work. 
> > IWatch/DWatch are two particular watchpoints or distinguished by access
> > type?  I.E. what would GDB need to know to know which it is setting?
> 
>  The watchpoints would always be interfaced the same way, regardless of
> the underlying implementation, of course.  For the IWatch/DWatch, I'd
> assign their numbers somehow (e.g. IWatch is watchpoint #0 and DWatch is
> #1, following the sequence used for their CP0 register numbers).  A user
> such as GDB would have to determine the capabilities of all watchpoints as
> I described and would discover that watchpoint #0 only accepts instruction
> fetch events and watchpoint #1 only accepts data read/write ones.
> 
>  This way we can accept an arbitrary underlying implementation.

This is what I don't like.  Setting each individual watchpoint to
determine their capabilities, when the kernel could just _report_ said
capabilities.  It's a difference in philosophy I suppose.  I also have
some concerns about making the probing indistinguishable from setting a
watchpoint; if MIPS37 or MPIS256 has a substantially different
watchpoint layout, we'll have to give it a whole new set of ptrace ops,
which defeats the point of abstracting it.

If we write up decent documentation for what a userspace implementation
has to do to probe the current implementations, I guess I'm satisfied.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: watch exception only for kseg0 addresses..?

[Maciej W. Rozycki]

On Wed, 11 Dec 2002, Daniel Jacobowitz wrote:

> >  The watchpoints would always be interfaced the same way, regardless of
> > the underlying implementation, of course.  For the IWatch/DWatch, I'd
> > assign their numbers somehow (e.g. IWatch is watchpoint #0 and DWatch is
> > #1, following the sequence used for their CP0 register numbers).  A user
> > such as GDB would have to determine the capabilities of all watchpoints as
> > I described and would discover that watchpoint #0 only accepts instruction
> > fetch events and watchpoint #1 only accepts data read/write ones.
> > 
> >  This way we can accept an arbitrary underlying implementation.
> 
> This is what I don't like.  Setting each individual watchpoint to
> determine their capabilities, when the kernel could just _report_ said
> capabilities.  It's a difference in philosophy I suppose.  I also have

 I'm not much fond of the idea of putting such things into the kernel,
especially as this means either storing additional, rarely used data in
the kernel or querying it each time a relevant ptrace() call happens.
Essentially the kernel needs to perform the same steps that a user program
would do, except it doesn't know what the results will be used for.

 Then, what do you expect to be queried by the kernel?  You certainly want
the number of watchpoints, and the AND-mask, the OR-mask and the event
trigger capabilities for each of them.  The latter implies both which
events are supported and which events imply (or exclude?) others.  This is
a lot of data, hard to express abstractly, possibly only partially needed
by different programs.  Why shouldn't each program be able to query
whatever it is interested in? 

 Besides, it's more kernel code and you probably know that a bug in the
kernel is less forgiving than one in the userland.

> some concerns about making the probing indistinguishable from setting a

 I consider it a strength of the interface -- this way watchpoints behave
exactly as probed by user software.  Anyway why do you need these
activities to be distinguishable?  When you are writing a program, you
certainly know what your code is meant to do.  You may comment it if
unobvious.

> watchpoint; if MIPS37 or MPIS256 has a substantially different
> watchpoint layout, we'll have to give it a whole new set of ptrace ops,
> which defeats the point of abstracting it.

 What can you expect to be added?  New events are trivial -- they are
added to the "access" member.  Old software ignores them (modulo bugs) as
it doesn't try to blindly activate them.  What remains is an address and a
mask.  They're generic, generic enough, not to be processor-specific, be
it MIPS or anything else -- how can they change?  They can only extend and
if they don't fit in 64 bits anymore, we need a new interface anyway.  We
may bump the version number then (but we'll need a new Linux port first). 

> If we write up decent documentation for what a userspace implementation
> has to do to probe the current implementations, I guess I'm satisfied.

 s/has/may/ -- otherwise I can't see a problem here. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +