Date: Mon, 11 Mar 96 13:12:31 MET From: Greg Lehey <lehey.pad@sni.de> To: erich@lodgenet.com (Eric L. Hernes) Cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), terry@lambert.org, hackers@freebsd.org (Hackers; FreeBSD) Subject: Re: using ddb to debug a double-panic? Message-ID: <199603111216.NAA16525@nixpbe.pdb.sni.de> In-Reply-To: <199603071424.IAA16678@jake.lodgenet.com>; from "Eric L. Hernes" at Mar 07, 96 8:24 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been thinking about it too, but for now it's quite useable > and that's the important thing. > > > > > I've been thinking about improving ddb. About 4 years ago, I wrote a > > similar kernel debugger for BSD/386, and was thinking of incorporating > > some of its features into ddb. One of the things it could do was > > exactly this kind of stack trace (well, it supplied other information > > as well). I won't get round to doing it until May, though. > > > > Does anybody else have ideas about improving ddb? > > > > yea, SCO's kernel debugger has a few more advanced features that > I kind of like, that probably wouldn't be too hard to implement: > a readline type history, This is one of the things I had planned. Does anybody object to emacs-style only, if the cursor functions work? > macros and user-defined functions, Yes, I suppose macros would be needed. I don't have them in lowbug, but I miss them. > casting and structure dumping (maybe done through macros), Yes, I think the macros are the way to go. Compare with adb. It would be nice to be able to load them from the system while it is running. Lowbug uses a system call to load the symbol table, and it wouldn't take much to extend it to handle macros as well. > watchpoints (do these work in ddb?), I don't think ddb has watchpoints. Lowbug has hardware breakpoints, which stop on specific memory access (read, write, or instruction fetch), and then has conditions on the breakpoints which would effectively make them watchpoints. Since it's all in hardware, it runs effectively at normal speed (the 486, at any rate, slows down fractionally in order to catch the correct address if you have a breakpoint set). The only problem is that you're limited to 4 breakpoints. > the single step execution holds your hand a bit better, and a couple > others. Any details? > I'd also like to be able to load in a new symbol table, such as when > an lkm is loaded. It may not be automatic, but it should be possible via the mechanism I described above. > Now it's only possible to debug loaded lkms, by running nm on the > module_mod output from the modload, and using the addresses from > that. I realize that this opens a can of worms wrt to multiple lkms > and unloading, but usually you've gotta reboot before that'd kill > you anyhow :). Maybe there's a better way to do this too. Well, the code is in place, though it could do with improvement. ------------------------------------------------------------ Terry Lambert writes: > Have you ever seen WINICE for Windows95? No. I try to keep away from that sort of "operating system". > No, it's not Windows-based, it's text based, but it allows > disassembly in several format, along with loading of symbol > information for kernel modules (VXD's and VPE's) and all sorts of > other nice, nice features. I'm sure there's something interesting here, but you haven't made it sound really exciting. What additional formats are of interest? I would think that one disassembly format would be enough. I've already described the possibility of loading symbols for lkms (in fact, lowbug will even load symbols for user processes, which can be useful in some cases). > Like the ability to install debug hooks in every one of your drivers > so that if you conditionally compile them with debug (be even better > if we supported segment ID's and kernel paging...), you extend the > debug commands with driver specific table dumping, etc.. I can see where you're pointing here, but it's a bit dim in the distance. How much does WINICE contribute to this process? It's obviously possible to include debug code in a driver even without a kernel debugger, and lowbug, at any rate, has a direct call entry point. Joerg Wunsch writes: > . a simple line editor with at least 10 lines of history Yes, I think this is a popular one. > . repeat the last `print' command by pressing enter only Lowbug does this already. There are some complications: do you want the same area of memory (usually not, in the case of print, but maybe in the case of reading io ports. > . inb/outb builtins They're there in lowbug. > . a `kill' command -- i always forget about the usage of `psignal()', > and the source code is usually not available in DDB... :-) That's an interesting one. Yes, I think we can do that. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603111216.NAA16525>