Bochs GUI for LINUX

[stlw]

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

I can't find it, could you post direct link, please ?

Thanks,
Stanislav

[bewing]

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

Sounds like a great plan to me. I'll keep checking it.

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

Wow, definitely a bug for Stanislav to fix. I always wondered if the param_tree could overflow. Clearly it can. It needs to be allocated bigger, obviously, but I don't know off the top of my head where it gets allocated.

80486sx: --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"..

Heh. A couple more for Stanislav. The nice thing is that he will probably fix them instantly, but then you will have to download a new CVS copy, and either overwrite or fix x.cc again.

@Stanislav: I will put everything together, convert the tabs, and send it to your gmail. It should be there in half an hour.

[stlw]

Wow, definitely a bug for Stanislav to fix. I always wondered if the param_tree could overflow. Clearly it can. It needs to be allocated bigger, obviously, but I don't know off the top of my head where it gets allocated.

Nice timing !
This bug was in CVS for one day exactly. Update to CVS latest !

Heh. A couple more for Stanislav. The nice thing is that he will probably fix them instantly, but then you will have to download a new CVS copy, and either overwrite or fix x.cc again.
@Stanislav: I will put everything together, convert the tabs, and send it to your gmail. It should be there in half an hour.

[/quote]

These are easier. Fixed in CVS between 3 to 4 months ago. The same recomendation - Update to CVS latest !

Stanislav

[bewing]

Brendan, thank you very much for doing all that testing. I appreciate it.

For the 64bit thing: Stanislav says above that he fixed it yesterday in a new CVS version. Hopefully it works.

For the FPU compilation error in a 486 emulation: I suspect he is mistaken that it is fixed, but I will need to look closer -- and in any case, you found a fix.

For displaying FPU registers: yes, those registers are always emulated by bochs, so I didn't bother trying to turn them off, ever. "Disabling" them doesn't do much (if anything).

For errors when debug is disabled, you don't really need to link in the enh_dbg.o file. But yes, if you want to run the compilation on the same files every time, then an #if BX_DEBUGGER around only the enh_dbg.cc file is sufficient. (The .h files will not be included, then.)

In the register display window, it says "EFLAGS = ???????" [and shows the value of CS]

Fixed, showing EFLAGS value now, I'll update the download shortly. (If you want to fix it in your own version, on line 793 of enh_dbg.cc, change rV to rV[EFL_Rnum])

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.

Uh ..... I was praying that I'd never have to show more than 8, because I couldn't visualize a slick way to handle it. There is an option to show only CPU0, even if there are lots of CPUs ... that would partially handle your first issue .... I might be able to squeeze 16 CPU buttons onto that row, legibly (if the window is wide enough) ... but do you have any suggestions on a nice way to enable a user to access a random CPU? Just make another command that asks a user type in a CPU number? How did QEMU do it?

If you keep resizing the window by moving the right border left and right (e.g. skinny, wide, skinny, wide), then the register dump grows

This is an integer truncation problem, and the user will be able to trivially handle it when I have the resizing function working again.

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 keeps growing until it's 4096 pixels wide.

Damn. I've been fighting this problem in GTK. GTK windows resize themselves to fit their contents. If the contents then resize to fit the window, you can get these infinite resizing loops. I'll work on this some more.

[Stevo14]

Hi,
You can add one more successful compilation to the list!
I had to do just a small amount different at the beginning to get it to work. Here's what I did.
I ran

Code: Select all

make dist-clean

I did the modifications as described in "X-install_instructions.txt"
Where it says:

Find the "LIBS =" variable assignment in the Makefile, approximately line 98. It is probably empty.

I had to put the modifications to the "LIBS =" line in Makefile.in, not Makefile. (this is so it wouldn't get overwritten every time I reconfigured)
Then:

Code: Select all

./configure --enable-sb16 --enable-ne2000 --enable-vbe --enable-all-optimizations --enable-x86-64 --enable-sep --enable-debugger --enable-disasm --with-x --enable-usb --enable-pci

Then I switched into the gui directory and ran

Code: Select all

g++ -c  -I.. -I../iodev -I../instrument/stubs -O3 -Wno-format -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/X11R6/include  enh_dbg.cc -o enh_dbg.o `pkg-config --cflags gtk+-2.0`

Lots of warnings printed, no error's though.
I then went back up to the bochs directory and ran

Code: Select all

make

and

Code: Select all

sudo make install

without any problems.

As far as the debugger itself, it seems to not like my window manager. It freezes whenever I move the window. Other actions make it freeze as well, like the multiple step dialog, the memory dump dialogs, etc.

As far as looks go, it looks very nice. The interface is very clean. The ability to turn on and off specific information in the options dialog is especially helpful. It also likes to freeze whenever I maximize the window but I assume everything expands and the scroll bars go away.

I didn't get a chance to really test and see if it is the window manager that doesn't agree with the graphical debugger (I use compiz and, ironically, my graphics card freaks out when it is not enabled...) but the debugger also freezes when I "rotate" the cube (which should really have nothing to do with the debugger...). This is the only application that has trouble with this on my computer.

[bewing]

Thank you. That was very interesting.

I hesitate to modify Makefile.in directly, because that is so permanent, and it violates the spirit of a configure script. I mean, even a "make dist-clean" won't make it go away again. You have to know what you are doing, and fix the Makefile.in back by hand. I don't think I can trust noobies to be able to do that.

As far as the "freezing" goes -- have you ever tried SDL on your system? I think I am just about to post an SDL version, and Combuster seems to think it might work with fewer of those sorts of issues. And I need a few guinea pigs.
Do you happen to know if this is the only app on your system that is built with GTK? And what version of GTK you have loaded?

Oh, also: no, the horizontal scrollbars do not go away -- they are the only thing that separates the upper window from the lower windows. It would look really funny if they went away.

[Stevo14]

Thank you. That was very interesting.

I hesitate to modify Makefile.in directly, because that is so permanent, and it violates the spirit of a configure script. I mean, even a "make dist-clean" won't make it go away again. You have to know what you are doing, and fix the Makefile.in back by hand. I don't think I can trust noobies to be able to do that.

Well, modifying Makefile.in was a hack. I only needed it because I missed the part where you configure before doing the modifications. I was configuring after the modifications, thus overwriting the modified Makefile. I'm very far from a configure/makefile expert (as demonstrated earlier ) but a more permanent solution might be to modify configure.in to add to LIBS when configuring with the x gui enabled. For example on line ~213 it adds "-lm" to LIBS if it detects that it needs to explicitly link with libm.a.

As far as the "freezing" goes -- have you ever tried SDL on your system? I think I am just about to post an SDL version, and Combuster seems to think it might work with fewer of those sorts of issues. And I need a few guinea pigs.

Yes, SDL works on my system. Most notably, Freeciv and Supertux use it. I would be happy to test that one as well.

Do you happen to know if this is the only app on your system that is built with GTK? And what version of GTK you have loaded?

I use Gnome so basically every app on my system (well, 75% - 80% of them) are GTK based. As far as building a gtk application on this system, I believe I have only ever built gtk-sharp apps (which, afaik, still use the same underlying gtk libs). My GTK version is 2.14.4 (both the dev packages and libs).

Oh, also: no, the horizontal scrollbars do not go away -- they are the only thing that separates the upper window from the lower windows. It would look really funny if they went away.

I mostly wondered if the register, stack, and disassembly lists would expand when the window is maximized so that there would be no need to manually scroll sideways to see the fully disassembled instruction (for example).

[Alboin]

Okay, I've had a little progress.

As of now, I've gotten rid of the

Code: Select all

enh_dbg.cc:(.text+0x9b1e): undefined reference to `num_read_watchpoints'
enh_dbg.cc:(.text+0x9b55): undefined reference to `read_watchpoint'
enh_dbg.cc:(.text+0x9d4e): undefined reference to `num_write_watchpoints'
enh_dbg.cc:(.text+0x9d85): undefined reference to `write_watchpoint'

Undefined errors. As it would turn out, these were all declared as static in my copy of bochs. (2.3.7)

All I have left is:

Code: Select all

iodev/libiodev.a(devices.o): In function `bx_devices_c::init(bx_mem_c*)':
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:247: undefined reference to `bx_ioapic'
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:246: undefined reference to `bx_ioapic'
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:247: undefined reference to `bx_ioapic_c::init()'
iodev/libiodev.a(pic.o): In function `bx_pic_c::raise_irq(unsigned int)':
/home/matt/Desktop/bochs-2.3.7/iodev/pic.cc:647: undefined reference to `bx_ioapic_c::set_irq_level(unsigned char, unsigned int)'
iodev/libiodev.a(pic.o): In function `bx_pic_c::lower_irq(unsigned int)':
/home/matt/Desktop/bochs-2.3.7/iodev/pic.cc:625: undefined reference to `bx_ioapic_c::set_irq_level(unsigned char, unsigned int)'
cpu/libcpu.a(apic.o): In function `apic_bus_broadcast_eoi':
/home/matt/Desktop/bochs-2.3.7/cpu/apic.cc:148: undefined reference to `bx_ioapic_c::receive_eoi(unsigned char)'

(BX_SUPPORT_APIC is set to 1 in config.h)

[bewing]

As it would turn out, these were all declared as static in my copy of bochs. (2.3.7)

Oh jeez. That was entirely my fault -- a thousand apologies. I made that change 4 months ago for the Windoze version of this code, and almost completely forgot about it -- it should have been in the install instructions.

All I have left is:

Code: Select all

iodev/libiodev.a(devices.o): In function `bx_devices_c::init(bx_mem_c*)':
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:247: undefined reference to `bx_ioapic'
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:246: undefined reference to `bx_ioapic'
/home/matt/Desktop/bochs-2.3.7/iodev/devices.cc:247: undefined reference to `bx_ioapic_c::init()'
iodev/libiodev.a(pic.o): In function `bx_pic_c::raise_irq(unsigned int)':
/home/matt/Desktop/bochs-2.3.7/iodev/pic.cc:647: undefined reference to `bx_ioapic_c::set_irq_level(unsigned char, unsigned int)'
iodev/libiodev.a(pic.o): In function `bx_pic_c::lower_irq(unsigned int)':
/home/matt/Desktop/bochs-2.3.7/iodev/pic.cc:625: undefined reference to `bx_ioapic_c::set_irq_level(unsigned char, unsigned int)'
cpu/libcpu.a(apic.o): In function `apic_bus_broadcast_eoi':
/home/matt/Desktop/bochs-2.3.7/cpu/apic.cc:148: undefined reference to `bx_ioapic_c::receive_eoi(unsigned char)'

(BX_SUPPORT_APIC is set to 1 in config.h)

Ah .... I vaguely remember seeing that set of errors once. Ummmm ... please try setting BX_SUPPORT_APIC to 0 and see what happens. I'll look back through my notes and see what I can remember.

but a more permanent solution might be to modify configure.in to add to LIBS when configuring with the x gui enabled. For example on line ~213 it adds "-lm" to LIBS if it detects that it needs to explicitly link with libm.a.

Yes, but unfortunately I am not guaranteed that every end-user's machine will have a copy of autoconf for me to run, to build a new configure script for them, after I modify their configure.in file.
But yes, that is how Volker or Stanislav (bochs developers) will solve it in the long run, for the next bochs release (in Jan, probably).

[Alboin]

Setting it to 0 doesn't even get to the linkage stage:

Code: Select all

g++ -c  -I.. -I./.. -I../instrument/stubs -I./../instrument/stubs -g -O2 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES    devices.cc -o devices.o
In file included from ../bochs.h:37,
                 from devices.cc:32:
../config.h:64:2: error: #error For multiprocessor simulation, BX_SUPPORT_APIC is required.
In file included from devices.cc:35:
../iodev/ioapic.h: In member function 'Bit8u bx_io_redirect_entry_t::destination() const':
../iodev/ioapic.h:45: error: 'APIC_ID_MASK' was not declared in this scope
../iodev/ioapic.h: At global scope:
../iodev/ioapic.h:75: error: expected class-name before '{' token
make[1]: *** [devices.o] Error 1
make[1]: Leaving directory `/home/matt/Desktop/bochs-2.3.7/iodev'
make: *** [iodev/libiodev.a] Error 2

Note: Setting BX_SUPPORT_SMP to 0 only removes the one error about it. The rest is the same.

[bewing]

Dang. Unfortunately, it looks to me like you started out with a screwey setup in your config.h somehow. Somehow my GUI code got compiled with SMP support turned on, but APIC support turned off. I can't understand how that happened, but I really think the best thing to do is start over, if you are willing. You can save your modified copies of x.cc and dbg_main.cc, so you don't have to modify them again -- but I really think that the best thing to do is run "make clean", make sure there is no extra copy of config.h in any subdirectory, and then run your configure script again. Sorry, but otherwise I'm stumped.

[bewing]

@Stevo14: When you say that the app "freezes" -- what is the extent of the freezing? Does just bochs lock up, and all the rest of your apps continue running OK? Or do all the X-apps lock up until you kill bochs? Or does it completely crash your X server?

[Stevo14]

@Stevo14: When you say that the app "freezes" -- what is the extent of the freezing? Does just bochs lock up, and all the rest of your apps continue running OK? Or do all the X-apps lock up until you kill bochs? Or does it completely crash your X server?

Just the debugger locks up. Everything else continues normally (all other X apps and the X server are fine). Bochs itself even continues running normally behind the debugger. When I say "locks up" or "freezes" I mean the interface doesn't respond and it eventually "gray's-out" and when I try to close it, a little window pops up saying, "The window "Bochs Enhanced Debugger" is not responding. Forcing this application to quit will cause you to lose any unsaved changes."
Force quitting it is the only way to shut it down.

[stlw]

So I see UNIX version of the debug frontend have much less users that Win32 version had
At least according to popularity/comments of this thread ...

Stanislav

[quok]

So I see UNIX version of the debug frontend have much less users that Win32 version had
At least according to popularity/comments of this thread ...

Stanislav

Unfortunately I haven't yet had the time to test this, but I fully plan on it.

Bewing, I'll even get it working with autotools for you, so it's fully integrated and hopefully that'll fix all these compile problems.

First though, I need to fix my wife's laptop, and evidently figure out what she did to her Palm that causes it to just reboot constantly, heh.

I hope to get to testing this new GUI later today, though!