Date: Tue, 23 Apr 96 16:23:20 MDT From: Greg Lehey <lehey.pad@sni.de> To: erich@lodgenet.com (Eric L. Hernes) Cc: hackers@freebsd.org (FreeBSD hackers) Subject: Re: request for a new "feature" as regards DDB Message-ID: <199604231423.QAA08117@nixpbe.pdb.sni.de> In-Reply-To: <199604231416.JAA20009@jake.lodgenet.com>; from "Eric L. Hernes" at Apr 23, 96 9:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
>>> 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. That's pretty much what lowbug does, except that there were no Pentiums when I wrote it, so no I/O access breakpoints. I suppose I should get hold of the Pentium book... I think that we should consider making these breakpoint forms more generally available (e.g. via ptrace ()). Do you feel like retrofitting gdb to use them? >>> 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 wouldn't call that a typical debugging sesseion. First, one of my intentions is to have the addresses of the functions available to ddb (they are to lowbug at the moment, though the implementation is pretty kludgy). Secondly, the ptrace () interface should also be able to specify whether you want a user-level or system-level breakpoint (i.e. does hitting the breakpoint stop the process or the kernel?). Thirdly, you would never want to use a kernel debugger to do things which a user-level debugger can do. But if you're debugging a system call, it's nice to be able to follow it back to the user level. > 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. Is this available on FreeBSD? I hadn't noticed... > 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. ;) See above for one scenario. I think we're in agreement. >>>> 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. Probably. Last time we talked about ddb, we were in agreement that we needed serial capability as well. >>> 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. Sure. The idea would be to connect to another machine running gdb or a user-level version of ddb. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604231423.QAA08117>