174 lines
8.3 KiB
Plaintext
Executable File
174 lines
8.3 KiB
Plaintext
Executable File
User tips: (ver 1.0)
|
|
|
|
The main user features available from the menus should be fairly obvious
|
|
to anyone who has used bochs -- but here are a few quick explanations, anyway.
|
|
These explanations include a few keyboard and mouse shortcuts that you might
|
|
not find through experimentation.
|
|
|
|
Terminology:
|
|
The Bochs guys call this GUI debugger interface the CI, to distinguish it
|
|
for themselves from the "VGA window" that shows the display of the simulated
|
|
computer. I will call this debugger GUI interface the "frontend". It's not
|
|
much better of a term, but oh well.
|
|
|
|
The text debugger interface that you are all familiar with is called the
|
|
Bochs Internal Debugger ("ID" for short).
|
|
|
|
The frontend is organized around 3 main "list-view" windows:
|
|
|
|
The Register window:
|
|
Typically, all the various registers are grouped by color. If you don't like the
|
|
colors, they can be turned off, or modified at compile time. There are options
|
|
to show or hide most register "groups", so that you can focus more strictly on
|
|
the registers you are interested in (probably just the GP registers).
|
|
|
|
Notes: Sometimes (on CPU mode changes, or when windows are being moved), the
|
|
System Registers (GDTR, IDTR, LDTR, TR) will appear on the Register list for
|
|
one "step". This is not a bug -- it is a kludge to get the columns to be the
|
|
right width.
|
|
|
|
Yes, the XMM display shows hex in the "decimal" column -- there is more
|
|
room there. Deal with it.
|
|
|
|
** Doubleclicking a register attempts to change its value. Bochs may not
|
|
allow you to change most registers. In future versions, more registers may
|
|
be modifiable.
|
|
|
|
The Disassembly window:
|
|
Disassembly output that is autoloaded, or generated from the menu, ends up
|
|
here. If the frontend cannot detect the "current instruction" in the list,
|
|
when it reaches the next instruction -- then it will autoload a new list.
|
|
Having a big list will reduce the number of autoloads, and allows you to see
|
|
more. The list can contain up to 2048 lines. However, if you load more than
|
|
1000 lines, you are likely to see big performance problems in Windows on
|
|
certain occasions -- like minimizing and then restoring the window. This is
|
|
a Windows bug/"feature".
|
|
|
|
Note: There are two kinds of emulated memory in bochs: Linear and Physical.
|
|
Emulated Linear memory is mapped onto Physical memory by x86 virtual memory
|
|
methods (paging and segmentation). If paging and segmenataion are "off", or
|
|
"identity mapped", then both "types" of memory mean the same thing. But they
|
|
still work a little differently. With the Internal Debugger, you can set
|
|
breakpoints to either kind of memory, separately. Normally, you would use
|
|
the "b" command to set breakpoints in physical mem, and "lb" to set breakpoints
|
|
in linear mem. This frontend ONLY displays linear breakpoints. It does not
|
|
bother trying to figure out the linear->phsical reverse mapping to show
|
|
physical breakpoints. (There are also "virtual" breakpoints that are also
|
|
not shown.) All the types of breakpoints still WORK, it is just that you
|
|
will not see them marked on the screen.
|
|
|
|
It will be obvious to you that the current instruction is marked in green,
|
|
unless it is on a breakpoint, when it turns blue. Breakpoints are red, of
|
|
course.
|
|
|
|
** You must click a line in the window, before you can use frontend commands
|
|
to set or clear a linear breakpoint on it.
|
|
** You can doubleclick (which saves steps) to set or clear a linear breakpoint.
|
|
|
|
** If you do a Find command to select a bunch of ASM lines, you can set linear
|
|
breakpoints to all of them at once, with the F6/Breakpoint command. However,
|
|
there is a limit compiled into bochs on the maximum number number of linear
|
|
breakpoints. The typical limit is TEN. Edit your config.h if you want more.
|
|
|
|
The MemDump window:
|
|
|
|
As of this version, the MemDump window isn't much more than a display of the
|
|
contents of memory. In later versions, hopefully it will be expanded into a
|
|
fairly fully-featured hexeditor. You can dump either phyical mem, or linear
|
|
mem. There are breakpoint-like things (that work with physical memory only,
|
|
currently), called "watchpoints". A physical memory address can cause a break
|
|
in the simulation if it is read, or written.
|
|
|
|
The frontend again does NOT try to calculate out the linear -> physical mapping
|
|
in any attempt to display the physical watchpoints while viewing linear mem.
|
|
|
|
You must click a hex byte (on a physical mem dump that shows bytes), in order to
|
|
set or clear a read and/or write watchpoint on that byte. Read watchpoints are
|
|
green (on black), write watchpoints are red, watchpoints that are both write
|
|
and read are blue. There is a hardcoded limit in bochs of 16 of each type of
|
|
watchpoint.
|
|
|
|
The MemDump window loads/shows 4K of memory at a time.
|
|
|
|
** PageUp/Down scrolls the display up or down through mem, 2K at a time.
|
|
** Doubleclicking a line of memory allows you to change the byte values.
|
|
(Works on both linear and physical mem dumps.)
|
|
** Doubleclicking with the Shift key down sets write watchpoints.
|
|
** Doubleclicking with Control sets read watchpoints.
|
|
** You can use both Shift and Control at the same time.
|
|
** You need to click once on the memory window before you can use its "Find"
|
|
function. The Find function is pretty limited in scope, currently. It can
|
|
only find bytes (or strings of bytes) within each 16byte "line".
|
|
|
|
|
|
Other windows:
|
|
|
|
The Output window shows anything that the Bochs Internal Debugger tries to send
|
|
to you. The window is scrollable, but only keeps a limited history of output (10K).
|
|
The ID is always spamming you with "Next at t=" and disassembly lines, that would
|
|
tend to fill up the Output window with garbage -- so there are options to ignore
|
|
either of these types of output.
|
|
|
|
The Input window is for sending user commands directly into the Bochs Internal
|
|
Debugger -- bypassing the frontend. Results will appear in the Output Window.
|
|
The Input window has a history feature for commands, using the Up and Down arrows --
|
|
it remembers 64 commands, 80 bytes each. No matter where you click on the frontend,
|
|
you can always type directly into the Input box without clicking on it.
|
|
|
|
When the Input window is invisible, you should still be able to type into it --
|
|
after taking into account the bug listed at the bottom of this file.
|
|
|
|
** Hitting Enter on a blank line will cause a Singlestep.
|
|
|
|
The Param Tree:
|
|
|
|
The bochs param_tree shows the internal state of most of bochs. It will be
|
|
expanded in the future to show even more. You can see the detailed state of
|
|
all cpu registers -- including the "hidden" parts (look in the "bochs" branch).
|
|
Or see the current state of most of the emulated hardware.
|
|
|
|
The Stack window:
|
|
|
|
The MemDump windows do not automatically refresh -- except for the Stack
|
|
window. If you leave the stack window active, it will update as the stack
|
|
changes. If you want to update the other MemDump windows with fresh data,
|
|
hit Refresh.
|
|
|
|
The Command Button row:
|
|
|
|
Just a (hopefully) convenient way of using the mouse, instead of the keyboard.
|
|
If you don't like them, or they take up too much space, you can turn them off.
|
|
|
|
The CPU Button row:
|
|
|
|
This only shows up when you are running a multi-cpu simulation. Click on the
|
|
CPU that you want to view. All CPUs are always stepped together, and they all
|
|
stop the first time one hits some sort of breakpoint.
|
|
|
|
Docking/Resizing:
|
|
|
|
If you grab one of the two vertical "bars" between the lists, you can horizontally
|
|
resize the lists. The cursor will change, but there will be no animation.
|
|
|
|
If you grab the middle of one of the lists, and drag it on top of one of the
|
|
other lists, you can reorder the positions of the lists on the screen. The
|
|
cursor will change, but there will be no animation. You can set an alternate
|
|
"docking order" at compile time, also, if you have a permanent preference.
|
|
(See the top of the wenhdbg_h.h file, for compile-time customization.)
|
|
|
|
Additional Notes:
|
|
|
|
If you have a really big GDT or Paging display in the MemDump window, and you
|
|
select a different display, it may take several seconds to delete the big display
|
|
before it can switch. Additionally, note the "windows feature" listed above --
|
|
it is not wise to minimize the display, if one of the lists is really big.
|
|
|
|
Uppercase text tends to seem a little annoying, but it really is a lot easier to
|
|
read, especially on a proportional font. If you change to a fixed font, then you
|
|
may want to switch the display to lowercase.
|
|
|
|
############
|
|
Known bug: if the frontend window is hidden or minimized, then restored -- you
|
|
will not be able to type into the Input window until you click somewhere.
|
|
|