Bochs: Difference between revisions

'''Bochs''' is a steadily improving simulatoremulator for the [[:Category:x86|IA32x86]] platform. AmongIt othergreatly nicetiesimproves (suchOS asdevelopment removingbecause the needvirtual formachine arestarts rebootmuch toquicker testthan yourreal latest kernel buildhardware, just restart Bochs),plus it offers detailed debugging functionality that can help greatly during kernel development.

It is strongly suggested to get two installations of Bochs - in addition to the out-of-the-box version (which might well be one of the binary downloads), you should also compile a second instance with the internal debugger enabled - so when something strange occurs that your 'normal' debugging tools can't trace, you can cross-check it with the debug version. You may also wish to enable (and use) the debug i/oIO ports.

You sent your code pointer (eipEIP) to some uninitialized memory area. This means you either followed a nullNULL (or uninitialized) pointer, or you damaged the return address of your [[Stack#Stack example on the X86 architecture|stack frame]]. Make your code more clean, test pointers before you follow them, initialize every pointer (especially those who are on the stack) and enable *-Wall* in GCC.

The CPU didn't manage to invoke an exception handler and would normally [[Triple Fault|triple fault]]. This is probably due to a bad [[Interrupt Descriptor Table|IDT]] register content, or a bad IDT descriptor. Sometimes (but less likely), it can also be due to a severe bug in your exception handler code. Check your exception works with "illegal" ASMasm instructions like <tt>idiv 0</tt>, or

pop ds ;; 0xf001 is no valid segment,

mov ax, ~[ds:0x12345678] ;; let's see if we get the GPF

Bochs performs some paranoiacrather paranoid checks on I/O operand size. Reading a byte from port 0x1234 is usually not the same thing as reading a dword32-bit value. Go back to your chip's datasheetdata sheet and double-check that your sizes are correct.

=== fetch_raw_descriptor: LDTR.valid=0 ===

Many of you have said "but ... I do not have an LDT and I read it wasn't mandatory!?". You're right. And so is BOCHSBochs. This message usually means that your program tried to load a selector with some garbage value, which happened to have the 3rd bit (Table Indicator) set. The CPU will try to look up the descriptor in the LDT, but there's no LDT registered! In most cases, the error comes from some mispairing of push and pop on the stack, which lead to a non-selector value to be loaded in a segment register.

If you're still stuck, download the Bochs sourcessource package and search for the message you received. Then, maybe you can add extra information to the message-printing code (like the faulty offset of a segfault, the segment limit, etc). But keep away from modifying Bochs' operations! Every time I suspected a bug in Bochs, I was just misunderstanding the Intel Manual...

;Bochs enables A20Linethe A20 line in the BIOS

:Your PC doesn't necessarily do so. Sometimes there's a BIOS option, sometimes there isn't. Check your code that enables A20Linethe A20 line and make sure it has no issues with faster hardware.

:Although Bochs does have these constructs, they do not work the same as a regular CPU cache/ or TLB and do not change based on which CPU is being emulated. If you're not handling caching or TLB refreshes correctly, behavior may differ in Bochs vs. hardware (ie,i.e. it may work on Bochs but not on hardware, or vice versa).

:In a normalphysical PC, it's common to issue up to 3 read commands on a sector/track before it can be read fine. If you don't have proper error check/recovery in your bootsector, you're likely to run something that is not your kernel...

:UnlikeDespite what Chris Giese's Protected Mode tutorial states, you do not have to be in 16-bit protected mode to clear the PE bit of cr0CR0. If you fail to enter 16-bit protected mode on a real PC, it will hang, without giving any error indication - no triple fault or anything!

;Bochs' timer is not realtimereal time

In windowsa Windows environment, add belowthis line to your bochsrc.bxrc

display_library: win32, optionoptions="gui_debug"

When you're using bochsBochs with the [http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html internal debugger], then you can trigger the debugger via a systemfacility called [http://bochs.sourceforge.net/doc/docbook/user/bochsrc.html#AEN2324 magic breakpoints]. To trigger a breakpoint, you can insert <tt>XCHGxchg BXbx, BXbx</tt> (in GAS syntax, <tt>xchgw %bx, %bx</tt>) anywhere in the code and bochsBochs will trap into the debugger as soon as it executes it. On real systemshardware this has no effect as it onlymerely replaces the BX register with itself.

You should put the following line in your bochsBochs configuration file to have it listen to magic breakpoints:

On older versions, enabling the debugger alone doesn't compile in magic breakpoint support, you will also need to passspecify <tt>--enable-magic-breakpoint</tt> towhen configuring the configurebuild foron those versions.

Bochs has many compile-time configuration options, some of which conflict, and therefore a binary distribution of Bochs may not be suitable for your purposes. I found it was best to compile my own copy of Bochs to be sure I had the features that I needed. Also, you should consider using the CVS snapshot version of Bochs if the released version is old and not working for you. I found this was necessary up until version 2.4 was released, for example. On Ubuntu, you may have to run

--with-x --with-x11 --with-term --with-sdl2

* Bochs has GDB- stub support, and its own internal debugger. These cannot be compiled into the same Bochs binary. The internal debugger is very useful, itits flag is --enable-debugger

* The GDB- stub in Bochs does not support SMP, last time I checked.