Date: 23 Nov 1998 21:49:46 -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: <86af1hn411.fsf@detlev.UUCP> In-Reply-To: Greg Lehey's message of "Tue, 24 Nov 1998 09:35:37 %2B1030" References: <AAnyMMsCYR@ns.online.samara.ru> <19981123205619.Q430@freebie.lemis.com> <86iug6mcnq.fsf@detlev.UUCP> <19981124093537.R430@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> I don't know what CPUs have instrumentation for this.
> All i386 architectures, in varying degrees.
Since I wrote that message, I dragged out my Intel docs so I could
follow along with the rest of the class.
>> (It might theoretically be possible with GDB using a semicomplex
>> series of isteps and tests, but it would slow down your system
>> possibly hundredfold.)
> 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.
Warning: Attempts to watch wired kernel memory may cause unrecoverable
error in some systems such as i386. Watchpoints on user addresses work
best.
> 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.
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.)
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.
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.
>> 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. I didn't
say that I/O breakpoints don't have their time and place, but they can
also be misused easily.
And now I hope that I'm not starting a holy war.
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?86af1hn411.fsf>