Date: 24 Nov 1998 00:48:27 -0600 From: Joel Ray Holveck <joelh@gnu.org> To: Greg Lehey <grog@lemis.com> Cc: SysAdmin <sa@ns.online.samara.ru>, freebsd-hackers@FreeBSD.ORG Subject: Re: breakpoint on i/o in kernel Message-ID: <86n25hy4ar.fsf@detlev.UUCP> In-Reply-To: Greg Lehey's message of "Tue, 24 Nov 1998 16:13:05 %2B1030" References: <AAnyMMsCYR@ns.online.samara.ru> <19981123205619.Q430@freebie.lemis.com> <86iug6mcnq.fsf@detlev.UUCP> <19981124093537.R430@freebie.lemis.com> <86af1hn411.fsf@detlev.UUCP> <19981124161305.W63366@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> The correct thing to do would be to implement I/O (and memory access) >>> breakpoints, not kludge it. >> Memory access breakpoints are already implemented: >>>> watch addr,size >>>> Set a watchpoint for a region. Execution stops when an attempt to modify >>>> the region occurs. The size argument defaults to 4. If you specify a >>>> wrong space address, the request is rejected with an error message. > Last time I looked, watchpoints worked by tracing the program and only > stopping if the condition was met. Are we talking about ddb or gdb here? I've only been lightly skimming the ddb code, but it looks like it uses the VMM; no single-stepping. gdb does what you suggest if there is no h/w support for watchpoints, or possibly if the number of watchpoints exceeds what the hardware can handle. The i386 has no h/w support presently. > That makes it ridiculously slow, especially if you're debugging over > a serial line. It also applies only for write access, not for read > access. There is that. But I think ddb uses the VM protection to trap writes, not single-stepping. > Here's the relevant part of the documentation for Lowbug (September > 1992): This is the debugger you made? It looks nice. I'd like to see the same functionality in kgdb. >>> I look at it once, and the code turned my stomach. >> Was this for kdb, ddb, or kgdb? I don't know much about ddb. > gdb. ddb is too limited to be of much use. Yes, but it's simple at least, and would be easily augmented for I/O traps from the look of it (which would solve the immediate problem). >> Going over its code, it appears that ddb uses the VMM to handle >> watchpoints instead of using the processor's debugging >> instrumentation. (This is fine with me, and more portable to boot.) > The question is speed. How does the speed differ using VMM vs. debugging exceptions? >> A quick review doesn't show any major problems implementing I/O >> breakpoints. Is there any reason that the same entry mechanism to >> enter ddb on a page fault couldn't also enter ddb on a debug >> exception? If that's the case, then it would appear that all we need >> to do is to write something to manage four I/O breakpoints and we've >> got the basics. > The main reason is that it's so slow as to be unusable. We have an > alternative which *is* usable. What is unusable? Single-stepping through? I'm not talking about that! What alternative? Lowbug? Does it still work? I'm suggesting adding commands to ddb and/or kgdb to allow manipulation of the CPU's debug registers. Admittedly, I don't know much about this facility, only what's in Intel's docs. But I don't know of any faster alternatives. How is what I'm proposing slow? >> gdb already has some instrumentation for hardware breakpoints; it may >> be extendable to allow for this sort of thing. I haven't looked into >> that. > It must be new, then. If you point me to it, I may take a look at it. gdb doesn't look like it has hardware support for the i386 yet. This is probably because the debug registers are only accessible from ring 0, so nobody felt it was worthwhile to add. The only platform I am aware of with hardware support is the SPARClite DSU. (The following is based on the gdb in -current.) However, the hbreak (hardware break) command is in place, and a quick review looks like watchpoints use hardware when they can. Look in breakpoint.c; grep for "hardware" to find key points. If you want to see a breakpoint structure allocated, start with hbreak_command and watch_command_1, and follow from there. Other highlights are insert_breakpoints (called to instrument the code and create hardware breakpoints / watchpoints), bpstat_should_step (called to check for software watchpoints), and target_insert_watchpoint (I don't know where that is). *** XXX *** To whoever hacks this: breakpoint.c:2447 seems to imply that hardware breakpoints are implemented using watchpoints. However the existance of separate functions target_insert_hw_breakpoint and target_insert_watchpoint would seem to imply differently. Please double-check that code. (For the i386 it may not matter, since 2447 tests the number of watchpoints remaining, which for us is the same as the number of hardware breakpoints remaining.) >>>> I generally recommend another method of debugging than I/O >>>> breakpoints. >>> That's a workaround, not a solution. I/O breakpoints are really >>> useful. >> Yes, but they are also frequently misused. I myself used to be a >> frequent debugger abuser, and would rely on the debugger instead of >> thinking about the driver and knowing what's going on wrong. > Sure, there's a certain tendency to do that. That doesn't make the > tool bad, though. I agree. I'm all for doling out rope, and letting the recipient judge whether to tie a ladder or a noose. That's why I say, "I generally recommend..." rather than "You should use...". Not knowing his situation, I don't want to make any judgements one way or the next. (You may also notice I'm considering implementing this.) Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?86n25hy4ar.fsf>