Skip site navigation (1)Skip section navigation (2)
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>