Date: Sun, 4 Jul 1999 10:53:39 -0400 (EDT) From: Brian Dean <brdean@unx.sas.com> To: peter@netplex.com.au (Peter Wemm) Cc: rivers@dignus.com (Thomas David Rivers), freebsd-hackers@FreeBSD.ORG Subject: Re: support for i386 hardware debug watch points Message-ID: <199907041453.KAA03044@dean.pc.sas.com> In-Reply-To: <19990703142624.ED06C64@overcee.netplex.com.au> from Peter Wemm at "Jul 3, 1999 10:26:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I've got some prototype code in place which supports the context switching part of this. It's pretty simple right now, as I'm trying to keep changes to a minimum. What I've done is simply added the dr0-dr3,dr6,dr7 registers to 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu_switch(), during a save operation, I load %dr7, and check the lower 8 bits, which indicate if any breakpoints are in use. If they are, I save all the debug registers, then clear out %dr7, which disables the breakpoints. During a restore operation, I load the value of %dr7 from the pcb structure of the new process, and if any of the lower 8 bits are set, I restore all the debug registers. This is not as efficent as it could be implemented with a separate flag to indicate whether saving the debug registers is necessary since loading/storing the debug registers is fairly expensive (11 clocks on an i486). This kernel is running right now and has not appeared to have suffered any ill-affects :) Now I'm asking for guidance for the cleanest way to hook into the rest of the kernel. Should 'struct reg' be extended to directly include the debug registers or should we go the route of having another data structure for the debug registers, not unlike how the floating point registers are handled? Extending 'struct reg' would be simplest in that I would merely need to modify the existing routines such as 'set_regs()' and 'fill_regs()' to set/save the additional registers. Also, doing it this way would minimize the changes required to 'ptrace()' in order to support setting and retrieving the new registers. However, I am unsure how existing code bases would be affected by such a change, i.e., we'd probably be breaking binary compatibility. Otherwise, I think I will need to set up a 'struct dbregs', provide the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. Comments? Either way, I think the changes to gdb would be minimal. It already supports hardware debug support. We'd just need to hook in our facility for setting/getting the hardware watchpoints at the apropriate place(s). Thanks, -Brian -- Brian Dean SAS Institute Inc brdean@unx.sas.com > To: Thomas David Rivers <rivers@dignus.com> > Cc: brdean@unx.sas.com, freebsd-hackers@FreeBSD.ORG > Subject: Re: support for i386 hardware debug watch points > Date: Sat, 03 Jul 1999 22:26:24 +0800 > From: Peter Wemm <peter@netplex.com.au> > > > Is there any interest in supporting something like this in FreeBSD? > > > I'm volunteering to spend some cycles on this, but I don't want to go > > > to the effort if there's little chance that the work would be > > > integrated. > > > > > > Thanks, > > > -Brian > > > -- > > > Brian Dean SAS Institute Inc brdean@unx.sas.com > > > > Brian - > > > > Scan through the mail archives - I brought this up about this > > time last year, I think... > > > > There were several responses - some people may be willing to > > assist... > > I'll chime in.. I'd be quite willing to bring something like this in, > assuming it was done reasonably cleanly. It shouldn't be too hard to do it > without imparing portability across cpu/arch types. > > I think this would be quite useful, especially if gdb could be made aware > of it too. > > > - Dave Rivers - > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907041453.KAA03044>