Bochs GUI for LINUX

[stlw]

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

config.h attached as requested.

bewing, I hope you will not require SMP to be enabled for the debugger GUI ?
It should be able to compile and work with/without SSMP, x86_64, sse, mmx, even fpu. Any Bochs configure options combination

Stanislav

[bewing]

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]

Hi,

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

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.

The 7 lines that are supposed to be manually added just before x11_notify_callback() are supposed to provide your missing references. Please check x.cc and make sure that modification #2 looks perfect, and also delete the x.o file and libgui.a, so that make is forced to rebuild them.

Code: Select all

#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

[stlw]

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

[quok]

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

Not only would I have preferred a patch against the Bochs CVS sources (or 2.3.7, whatever), but personally I'm not going to jump through hoops to get this to compile just so I can go bug hunting. Bewing, PLEASE integrate your sources with the bochs build system. It would stop a LOT of these problems that people are having getting your code to compile. Once that's done, I'd be more than willing to give this enhanced debugger of yours a try.

[Brynet-Inc]

^^ What he said.

[bewing]

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

[Brynet-Inc]

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

...ZOMG REALLY??

You could have modified the relevant support files, and we could have regenerated the configure script ourselves.

THAT would have been the correct way to do things.. for ANY platform, not just "LINUX".

[bewing]

You are free to explain to me precisely how to do it, rather than just complain, you know. I am not an autoconfig expert. And modifying the bochs autoconfig support files is something that bochs developers like Stanislav do, not people like me, who are only providing "plugins". And perhpas you noticed that I clearly labeled this as being a preliminary download?

[stlw]

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

bewing, you could modify Makefile.in, it is not very different from Makefile that you suggest to modify.
Also you could try to talk with Volker and ask for his help about modifying configure script.
Might be he would suggest you how to reduce library dependencies of your stuff as well. For example, not sure you can't live without pthread.
Add please, convert tabs to spaces - people have different editors with different tabs sizes - the code mixing tabs and spaces just unreadable in some editors.

Stanislav

[bewing]

pthread is absolutely required by GTK. The gtk_main loop is an infinite loop, and never returns. Without the one extra thread for that infinite loop, bochs would lock up forever.

I am certainly planning to do all those trivial things, once I can find out what the major compilation errors are.

[Brendan]

Hi,

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.

Doh - someone inserted these lines at the wrong place.

I got a few new problems. First, GCC complained that "InitDebugDialog()" wasn't defined in the current scope (line 656 in "x.cc"), so I fixed it by adding a "extern void InitDebugDialog(void *);" near the top of the file. 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!

I do have some suggestions though:

• 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".

Overall, I'll give it a score of 9.9 out of 10..


Thanks,

Brendan

[bewing]

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

Oops! I wonder how that one slipped by me.

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...

Huh. I thought I had tracked all of those down. Guess there is one left! I will try some more debugging to find it and fix that.

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

Yay! One successful installation! Are you interested (now that you've got good sourcecode) in trying to compile it for 64bit, with lots of bochs options, rather than your original minimal configuration?

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

Well, you can type p<CR> in the Input window (to do it the old-fashioned way), or F8 is an undocumented substitute, or you can just doubleclick to set a breakpoint (I mean, is it really that hard?). The logic to implement that p/proceed/next/trace/step over command is unbelievably ugly, and I keep wanting/hoping to get rid of that 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]

Uh??!? EEK! It's SUPPOSED to! The current EIP in the disassembly window is always supposed to be colored green (text foreground), it is supposed to constantly update and track EIP. When it gets close to the bottom of the screen, the screen is supposed to autoscroll downward a little ways, to keep EIP in the middle! That part of the code has been tested a million times!!?! How can it not be working for you? Huh!
You are never supposed to need to hit ctl-D. I will look into it, but could you please test that a tiny bit more, and verify that none of those things (color, autoscroll) are working?

... maybe I should add some other visual indication (besides foreground color) of EIP for non-color displays, too .... Hmmm.

Cheers,

Bruce

[Brendan]

Hi,

I'm going to keep adding results to this post...

Enable Everything: Every "./configure" option enabled
Status: Compiled, didn't run. Error message was:

Code: Select all

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

Fix: I couldn't find one..


80486sx_db: --enable-cpu-level=4 --disable-fpu
Status 1: Failed to compile, error message was:

Code: Select all

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

Fix 1: Wrapping the 2 pieces of code with "#if BX_SUPPORT_SSE > 0" and #endif" seems to fix this.
Status 2: Failed to compile, error message was:

Code: Select all

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'

Fix 2: Hehe. Don't use "--enable-apic"..
Status 3: Working very nicely!


80486sx: --enable-cpu-level=4 --disable-fpu --disable-debugger
Status 1: Failed to compile, error message was:

Code: Select all

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'

Fix 1: Put the following 2 lines at the start of both "enh_dbg.cc" and "enh_dbg_os_specific.h"; and put an "#endif" at the end of both these files:

Code: Select all

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

Status 2: Works perfectly!


pentium_db: --enable-cpu-level=5 --enable-fpu --disable-mmx
Status: Worked fine!
Note: When you select "Show FPU/MMX registers" from the "options" menu, it dislays FPU and MMX registers, even though MMX is disabled. I'd consider this a minor quirk rather than a bug...


pentium: --enable-cpu-level=5 --enable-fpu --disable-mmx --disable-debugger
Status: Worked fine!


p3_db: --enable-cpu-level=6 -enable-mmx --enable-global-pages --enable-pae --enable-large-pages --enable-mtrr
Status: Worked fine!


p3: --enable-cpu-level=6 -enable-mmx --enable-global-pages --enable-pae --enable-large-pages --enable-mtrr --disable-debugger
Status: Worked fine!


p4_db: --enable-cpu-level=6 --enable-global-pages --enable-pae --enable-large-pages --enable-mtrr --enable-sse=2 --enable-daz --enable-xsave
Status: Worked fine!


p4b_db: Exactly the same as "p4_db" above, but with "--enable-x86-64" instead of "--disable-x86-64"
Status: Compiled, didn't run. Error message was:

Code: Select all

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

Fix: Still haven't found one..


p4b_db: Exactly the same as "p4b_db" above, but with " --disable-debugger"
Status: Compiled, didn't run. Error message was:

Code: Select all

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

Fix: Still haven't found one..


Enable Almost Everything: Every "./configure" option enabled, except "--enable-x86-64"
Status: Worked fine!


Misc/general Notes

Some notes for all versions:

• 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.

Conclusion

With a few changes, everything works well unless you attempt to emulate a 64-bit CPU. Attempting to emulate a 64-bit CPU never works, even if the debugger is disabled. It'd be interesting to see if the original CVS version of Bochs was able to emulate a 64-bit CPU...

Until this is fixed, I can't really test any other combinations of configure options, so I'm going to give up for today.


Cheers,

Brendan

[bewing]

OK, I just posted an updated copy at the beginning of this thread.
Things that should be fixed:
-- All of the GPOINTER_TO_INT casts
-- The instructions for modifying x.cc should be a bit clearer
-- "extern"s added to function prototypes in x.cc code, just in case
-- prototype for InitDebugDialog
-- current RIP is now bold for extra visual feedback
-- breakpoints are now italic for extra visual feedback

Things that are not fixed:
-- whatever is causing Brendan's gtk-CRITICAL non-widget error
-- Alboin's problems
-- The HAVE_HASH_MAP thing seems to be an incompatibility between new versions of GCC and all non-CVS versions of bochs -- setting it to 0 seems to be the right workaround
-- Some kind of magic automated install patch