Date: Fri, 25 Sep 1998 12:59:15 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, hackers@FreeBSD.ORG Subject: Large project: Improved debugger (was: Idea for a small project...) Message-ID: <19980925125915.A12701@freebie.lemis.com> In-Reply-To: <98Sep25.091619est.40331@border.alcanet.com.au>; from Peter Jeremy on Fri, Sep 25, 1998 at 09:16:36AM %2B1000 References: <98Sep25.091619est.40331@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry, I didn't see this (the subject line didn't attract me enough...) On Friday, 25 September 1998 at 9:16:36 +1000, Peter Jeremy wrote: > On Wed, 23 Sep 1998 21:20:24 -0400 (EDT), Thomas David Rivers <rivers@dignus.com> wrote: >> The Pentium chip has improved support for debugging programs, including >> a hardware assisted databreak manager. > > Note that this feature pre-dates the Pentium. I think it was introduced > with the 386, it's definitely part of the 486. Correct on both counts. IIRC you have four debug registers which can break on instruction fetch, data read, data write or I/O. I implemented a kernel debugger (Lowbug) which included these features for BSD/386 back in 1992. >> A nice improvement to FreeBSD would be to improve the ptrace() support >> so that it used the hardware assisted feature when running on a Pentium. > > And to modify GDB so it supports them. This latter task shouldn't be > too difficult since GDB already supports i386 hardware watchpoints on > both Linux and SCO. I looked at this a year or two after writing the debugger. The code really turned me off, and I decided that it *would* be too difficult. >> The feature is limited in the number of breakpoints you can manage; >> extra credit would be to not expose this limitation. > > This doesn't belong in the kernel. ptrace(2) should just make the > existing debug registers visible to a debugger (this is what GDB > expects). I'm not sure if GDB transparently handles switching between > hardware and software watchpoints. > >> Use the hardware >> break point feature for the first N watch points (I believe N would >> be 4 in this case) > > I believe you can have a total of 4 hardware watch/breakpoints, but > I don't think that a single hardware watchpoint is sufficiently > general to allow watching an arbitrary C variable (ie watching one > variable may need more than one hardware watchpoint slot). That depends. Again from memory, I think you can specify the width of the object which is accessed (1, 2 or 4 bytes). > Note that implementing this will require the debug registers to be > saved on a task switch, which means struct user will change, so it's > not totally trivial. I once tried to port Lowbug to FreeBSD. I didn't succeed (mainly lack of time; I had expected it to drop in, and it got caught on a rough edge on the way in), but I have for some time been thinking about a reimplementation of a debugger. I don't really like gdb, and it would be nice to have the same interface both within the kernel and outside it. I've been holding off for a number of reasons, one of them that I didn't really want to reinvent the wheel for a.out, but that's no longer a problem. So... What I propose is: - Debugger for both userland and kernel, including both kind of crash dumps. - No deliberate restrictions on portability, but no attempt to make it as portable as gdb (with the consequent lack of legibility). - Should do everything that current debuggers can do, and then some. This last point is the problem, of course. Lowbug had some features that other debuggers don't, but it was also missing some features, notably disassembly and access to source files. It's obvious that it needs them. But what else does it need? I'd welcome other ideas. For example, how important is gdb compatibility in the debugger commands and debugger output? I personally think that the gdb syntax is less than pleasant. I suppose it's time to come up with a feature list, which I'll keep up-to-date at http://www.lemis.com/debugger.html. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key 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?19980925125915.A12701>