Re: watch exception only for kseg0 addresses..?

[Daniel Jacobowitz <dan@debian.org>]

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