Date: Tue, 23 Apr 1996 09:16:04 -0500 From: "Eric L. Hernes" <erich@lodgenet.com> To: Greg Lehey <lehey.pad@sni.de> Cc: erich@lodgenet.com (Eric L. Hernes), hackers@freebsd.org Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604231416.JAA20009@jake.lodgenet.com> In-Reply-To: Your message of "Tue, 23 Apr 1996 15:48:33 MDT." <199604231348.PAA05671@nixpbe.pdb.sni.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey writes: >> > >> I'll probably whip up something rudimentary in the next couple >> days, but full blown support in ddb would be nice. > >What are you planning to do? oh, probably just some simple functions like set_hw_bp(addr, type, size) and clear_hw_bp(addr) where type is as defined in chapter 17 of the pentium book, (0 == execution, 1 == data write, 2 == io read/write, 3 == data read/write) I'll have to enable DE in CR4 for the io port breakpoints, which'll break on anything less than a pentium, but I've only got pentiums here to test with. > >> BTW has anyone used the watchpoints claimed to be available in ddb? >> It looks like it goes through the vm system, does that make sense? >> The man page says that watchpoints on user space work best, what >> sense does it make to put a kernel watchpoint on a user address? > >Why not? One of the things I don't like about ddb (and most other >kernel debuggers, for that matter) is that they don't take the user >environment into account. Maybe the problem is that the watchpoints >slow the kernel down too much. In lowbug, you can set a condition for >a breakpoint (or watchpoint, which I prefer to call memory access >breakpoints) only to happen on behalf of a specific pid. so this is a typical debugging session: 1) run nm on the program to get the address of functions. 2) escape to ddb to set breakpoints 3) run the program 4) play around in ddb 5) continue I've found gdb much easier to debug user programs. Now days you can even attach gdb to the program and get much of the per-process stuff. I don't dispute that there may be times where using a kernel debugger to debug user-space would be useful, maybe even necessary, I just haven't run across them yet. ;) > >>> On the other subject, changing out of X into character mode: I believe >> >> SCO uses dbtty(0|1) to switch from vt0 to sio0 on the fly, > >This would require appropriate support in the tty driver. I don't >know if I like that. well, the tty driver already supports a full blown serial console, so it shouldn't be too tough. > >> they >> also note that the serial line is not initialized in any way, so if >> you've got a mouse sitting there, it's now you're console. I'd >> say this is probably one of the better ways to handle this situation. > >Putting the console on the mouse is good? My mouse isn't that >intelligent :-) But yes, going serial if the VGA is in X mode is >probably a good idea. well, no not on the mouse ;). I was thinking that you'd either set the debug serial port to sio1, or put the mouse there, we'd have source code so it wouldn't be that tough. > >Greg > eric. -- erich@lodgenet.com http://rrnet.com/~erich erich@rrnet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604231416.JAA20009>