Re: watch exception only for kseg0 addresses..?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux