Date: Mon, 11 Mar 1996 13:16:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lehey.pad@sni.de (Greg Lehey) Cc: erich@lodgenet.com, joerg_wunsch@uriah.heep.sax.de, terry@lambert.org, hackers@freebsd.org Subject: Re: using ddb to debug a double-panic? Message-ID: <199603112016.NAA03753@phaeton.artisoft.com> In-Reply-To: <199603111216.NAA16521@nixpbe.pdb.sni.de> from "Greg Lehey" at Mar 11, 96 01:12:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Here is a budgo screen shot. Three overlay windows are shown, with the bottom window being the default debugger display. The first window is the register window. When a value is changes by an operation it is highlighted by being shown in cyan instead of white (PC color naming for text displays). The "o d I s z a P c" is a flags status area. The "I" and "P" are uppercase (and cyan) because the last instruction to be executed caused those flags to change. The second window is the data window. The "byte" indicator shows that the contents of the window resulted from a "db" command. The "dw" and "dd" commands dump 2 and 4 byte quantities, respectively. The dump is on the basis of clustering the hex values in 2, 4, and 8 "digit" values, respectively. This is to ensure direct readability without byte order dependency. The location of the ASCII translation for the dump data doesn't move (ie: the hex codes are space-compressed left). The third window is the disassembly window. This is the default mode being shown here. There is also the ability to say "code on" at a prompt, which would result, for instance, in the line: 0028:C02A545C AND BYTE PTR [EBX+03],7F Being shown as: 0028:C02A545C 8063037F AND BYTE PTR [EBX+03],7F Instead. Windows delete from the top down; that is, if the register window were not shown, the data window would be at the top of the screen, etc. Windows are easily toggled using Alt-F1 for the register window, Alt-F2 for the Data window, and Alt-F3 for the disassembly window. The location of the current instruction pointer is highlighted in the disassembly window. The final window, actually, the underlying window on which the others are overlaid, consists of all remaining screen lines, save the last line which is a black-on-cyan status line, containing command context sensitive help, or by default, "Enter a Command or ? For Help" (the fake screen shot shows the status line help for a partial input of a command beginning with "d"). Address references for which a symbolic name exists are shown as symbols. It is possible to load symbols for loadable modules. In FreeBSD, this really is an issue with putting symbol code and link code into the kernel itself (symbols must exist to be reexported; Microsoft handles this for their own VXD's by associating a .LIB file with each VXD and forcing dependent VXD's to be linked against the proper LIB. This is actually inferior to the ability to truly dynamically relink). Perhaps the most important thing is that the video card services are fully virtualized. That is, when I hit a kernel breakpoint while in a graphic mode or in a DOS shell (or in the BSD case, if I panic), the card state is restored without having to appeal to a process like the X server, which can't possibly be running in the case of a breakpoint in something like the VM system. I can put the screen into 43 or 50 line mode to allow me to make the windows larger. Editing capabilities exist for the register and data windows, and it is possible to assemble code from the command line by entering into a code input mode. Instructions being replaces during an edit are changed to one by NOP's for "short" instructions to keep the followon code valid. Finally, the function keys can be bound to specific sequences; some of the defaults are "step around", "step into", "go", etc. -- the same bindings for the visual debugger. The windows are size adjustable, and the default configuration is communicated to the debugger on system startup (it is, in fact, possible to cause the debugger to trace the full OS load process once the OS is present enough to allow it to run. For BSD, this would include starting a second processor, starting the init process, mounting the root FS, etc.). Bugdo screen shot: =============================================================================== EAX=00000800 EBX=C0FCE34C ECX=00000001 EDX=00000000 ESI=C00489A7 EDI=00000000 EBP=C33E2F70 ESP=C33E2E08 EIP=C02A5445 o d I s z a P c CS=0028 DS=0030 SS=0030 ES=0030 FS=0030 GS=0030 --------------------------------------------------byte--------------PROT---(0)-- 0030:00000000 9E 0F C9 00 65 04 70 00-16 00 2E 05 65 04 70 00 ....e.p.....e.p. 0030:00000010 65 04 70 00 54 FF 00 F0-43 EB 00 F0 EB EA 00 F0 e.p.T...C....... -------------------------------------------------------------------------PROT32- 0028:C02A5442 CALL [EBX+0C] 0028:C02A5445 POPAD 0028:C02A5446 RET 0028:C02A5447 XOR EBX,EBX 0028:C02A5449 XCHG EBX,[C00A41B0] 0028:C02A544F OR EBX,EBX 0028:C02A5451 JZ C02A54A5 0028:C02A5453 MOV AL,[C00A41B4] 0028:C02A5458 TEST AL,80 0028:C02A545A JNZ C02A5471 0028:C02A545C AND BYTE PTR [EBX+03],7F ------------------------------------VKD(04)+05E2-------------------------------- :x :x :db 00000000 :u C02A5442 :d D, DATA, DD, DB, DEX, DL, DS, DT, DW =============================================================================== Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603112016.NAA03753>