OSDev.org

Alboin wrote:Okay, enabling SMP seems to get rid of some of the errors.

config.h attached as requested.

Brendan wrote:Hi,

I'm getting undefined references in "enh_dbg.cc" too...

#if BX_DEBUGGER
char *debug_cmd = NULL;
bx_bool debug_cmd_ready = 1;
bx_bool vgaw_refresh = 0;
void ParseIDText (char *p);
void HitBreak();
#endif

bewing wrote:No, I don't require it. It is exactly the same as the Windows version that you have -- it supports all modes. All I was noticing is that he was getting undefined references to bx_cpu_array[], which is only supposed to happen if you compile the gui code with SMP support turned on, and then compile the rest of bochs without it. But something seems screwey with his config.h somehow.

stlw wrote:

bewing wrote:No, I don't require it. It is exactly the same as the Windows version that you have -- it supports all modes. All I was noticing is that he was getting undefined references to bx_cpu_array[], which is only supposed to happen if you compile the gui code with SMP support turned on, and then compile the rest of bochs without it. But something seems screwey with his config.h somehow.

bewing, everybody in UNIX have patch tool so you could avoid a lot of problems if you send a patch what applies your new code into CVS or 2.3.7 release.
(I prefer CVS of course)

Stanislav

bewing wrote:YOU CANNOT PATCH AN AUTOCONFIG MAKEFILE! I would have made a patch if I could have. Deal with it! Sheesh.

bewing wrote:YOU CANNOT PATCH AN AUTOCONFIG MAKEFILE! I would have made a patch if I could have. Deal with it! Sheesh.

bewing wrote:Thanks, Brendan -- your problem looks much simpler.
All of your errors are related to the x.cc file. Especially to modification #2 in the x.cc file, from the install instructions -- but this error would also happen if x.cc did not get modified at all.

• there's currently no way (that I could find) to use the "n|next|p - execute instruction stepping over subroutines" command, which can be quite useful in some cases (like when you reach a "rep stosd" and you're too lazy to put a breakpoint in), and
• It'd be nice if the disassembly window could track EIP while you're single-stepping (e.g. add a "track EIP" mode, and make the disassembly window scroll so that the next instruction is always at the top if the debugger is in this mode), so you don't have to keep pressing "control+D".

Brendan wrote: I got a few new problems. First, GCC complained that "InitDebugDialog()" wasn't defined in the current scope

Also, on the Bochs output window I get "(.:23828): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed", but this doesn't seem to matter...

It all seems to work perfectly!
..and it looks very very nice!

there's currently no way (that I could find) to use the [p command]

It'd be nice if the disassembly window could track EIP while you're single-stepping (e.g. add a "track EIP" mode, and make the disassembly window scroll so that the next instruction is always at the top if the debugger is in this mode), so you don't have to keep pressing "control+D".[/list]

[CTRL ] add param 'pending_INIT' to bx_list_c 'cpu0': list capacity exceeded

dbg_main.cc: In function 'void bx_dbg_lin_memory_access(unsigned int, bx_address, bx_phy_address, unsigned int, unsigned int, unsigned int, Bit8u*)':
dbg_main.cc:586: error: expected initializer before '*' token
dbg_main.cc:588: error: 'xmmdata' was not declared in this scope
dbg_main.cc: In function 'void bx_dbg_phy_memory_access(unsigned int, bx_phy_address, unsigned int, unsigned int, Bit8u*)':
dbg_main.cc:624: error: expected initializer before '*' token
dbg_main.cc:626: error: 'xmmdata' was not declared in this scope

cpuid.cc: In static member function 'static void bx_cpu_c::CPUID(bxInstruction_c*)':
cpuid.cc:281: error: 'class bx_cpu_c' has no member named 'msr'
cpuid.cc:307: error: 'class bx_cpu_c' has no member named 'msr'

gui/enh_dbg.o: In function `Close_cb(_GtkWidget*, void*)':
/ostest/bochs-20081201/gui/enh_dbg_os_specific.h:1342: undefined reference to `bx_dbg_quit_command'

#include "../config.h"
#if BX_DEBUGGER

[CTRL ] add param 'pending_INIT' to bx_list_c 'cpu0': list capacity exceeded

[CTRL ] add param 'pending_INIT' to bx_list_c 'cpu0': list capacity exceeded

• In the register display window, it says "EFLAGS = ???????" when it should say "CS = ???????".
• SMP looks very impressive with 8 CPUs (one button per CPU). However, normally I hack my copy of Bochs to support many more CPUs (up to 255 sometimes) because it's the only way to test if my OS supports a large number of CPUs properly, and it's the easiest way to find things like re-entrancy problems and live-lock. Now that Qemu is dead (won't compile on modern versions of GCC and won't work on 64-bit OSs if you do switch to an old version of GCC) I'll be looking forward to see how the graphical debugger handles it...
• If you have the debugger in a window (not full screen) and you keep resizing the window by moving the right border left and right (e.g. skinny, wide, skinny, wide), then the register dump grows leaving the disassembly and the memory display with decreasing space, until eventually you can't reduce the size of the window anymore. Once you reach this state, it's fun to maximize it (make it fill the screen) and then restore it again (so it's not full screen) - in this case it restores the window to it's previous size, but then the window grows on it's own until it's too large for the screen and only stops growing when it's about 2.5 times wider than the screen. Note: I'm using 1680 * 1050 screen resolution, so I'm guessing the window keeps growing until it's 4096 pixels wide.