OSDev.org

I finally got around to hacking the auto-foo so that bewing's code is all integrated. Here's my patch. This patch is against bochs CVS as of Dec 22 2008 @ 05:00 GMT. I have no idea if bewing's changes revert anything from CVS between the 2.3.7 release and my checkout today, unfortunately.

The patch includes all of bewing's code plus my changes to configure.in and the configure script. I didn't want to count on anyone having autoconf installed (or knowing how to use it) so I ran it myself.

These changes compiled on my machine (Debian Lenny/Sid) with a fair amount of warnings, and with nearly all the configure flags enabled. I did not add a new flag for the debugger code as a cursory glance shows that the new win32 debugger is always compiled when the debugger is enabled and the gui is win32. I figured it would be best to emulate that here.

Apply the patch with the standard -p1 switch, like so: cd bochs && patch -Np1 -i ../bochs-x11-enhanced-gui.patch

After the patch has been applied, it's a standard CMMI procedure. The minimum required configure switches are --enable-debugger --enable-disasm --with-x.

Then a make, followed by make install. No more messing with changing the code yourself, or finding all the paths and libs needed because of GTK. Hopefully this will solve all the problems people have been having with compiling bewing's patch.

It should compile with anything you throw at it. I'm still compiling it with a bunch of different options to make sure it all plays nice, but I haven't actually tested a compiled version just yet.

EDIT: Removed a couple of generated files and .CVS/* entries from the patch that shouldn't have been there. Converted all line endings in enh_dbg.cc from DOS to UNIX.

@JAL: OK, your format suggestion is very reasonable and easy.

But can either/any of you who can get it to compile duplicate Brendan's issue with a maximize/restore causing an infinite resizing loop?

bewing wrote:@JAL: OK, your format suggestion is very reasonable and easy.

I might have more when I'm actually going to use it, but this one struck me at first glance. Didn't have the time to fix myself, or I would've, though.


JAL

quok wrote:I finally got around to hacking the auto-foo so that bewing's code is all integrated. Here's my patch. This patch is against bochs CVS as of Dec 22 2008 @ 05:00 GMT. I have no idea if bewing's changes revert anything from CVS between the 2.3.7 release and my checkout today, unfortunately.

Boys, wait a second. I probably miss some basic thing. The new bewings code supposed to be kind of multiplatform, i.e. it should work fine for both Win32 and X-Windows hosts. The Win32 support is already integrated to CVS and I hope it will keep working at least as good as it works now.
But the patch quok posted here completely removes Win32 supports and keeps X-Windows ONLY alone, as I see.
I am still hoping to see kind of patch which I could try to apply to current CVS and try to test BOTH Win32 and X-Windows - but it is not exists
bewing, there is a big difference between 2.3.7 and current CVS, especially Win32 enh debugger integrated.
I can't track all the things that were removed by this or another patch originally based on 2.3.7 - this is just makes improssible to integrate it !
I am still hoping to get sometimes a single patch which I could merge with CVS tree.

Stanislav

stlw wrote: Boys, wait a second. I probably miss some basic thing. The new bewings code supposed to be kind of multiplatform, i.e. it should work fine for both Win32 and X-Windows hosts. The Win32 support is already integrated to CVS and I hope it will keep working at least as good as it works now.
But the patch quok posted here completely removes Win32 supports and keeps X-Windows ONLY alone, as I see.
I am still hoping to see kind of patch which I could try to apply to current CVS and try to test BOTH Win32 and X-Windows - but it is not exists
bewing, there is a big difference between 2.3.7 and current CVS, especially Win32 enh debugger integrated.
I can't track all the things that were removed by this or another patch originally based on 2.3.7 - this is just makes improssible to integrate it !
I am still hoping to get sometimes a single patch which I could merge with CVS tree.

Well I don't see where my patch removes support for the Win32 debugger. As you said, the win32 frontend is in current CVS and my patch is against CVS. I haven't tested making sure the windows side of things still compiles because I currently don't have access to a windows machine that I can test on, heh. However I also didn't really mean to explicitly support the Win32 version with this patch, as the whole reason I did this patch was to make compiling of the GTK based debugger easier for those that want to test it. I certainly didn't mean for this patch to get directly integrated into the Bochs tree. As I pointed out when I posted it, and as you did as well, there's huge differences between 2.3.7 and current CVS. I completely missed that bewing's code was based on 2.3.7 when I grabbed current CVS to make my patch.

I'll re-work my patch this week so it is based on 2.3.7 instead, but I doubt I'll be able to test compiling it on Windows to make sure I didn't break anything. Other than that though, I don't plan on supporting this patch all that long. I'm just trying to make it easier for folks to test bewing's code.

Bewing - if you have a more recent version of your code that is based on Bochs CVS, please let me know, and I"ll re-work my patch against that.

I was also not considering this current beta-version of the GTK frontend to be anywhere near being ready to integrate into bochs, yet.

I made some enormous modifications from the CVS version, to get to this GTK version. That is, I separated ALL the Win32 code from the "backbone" of the debugger, and put the Win32 code into a separate Win32 OS-specific .h file. Then I rewrote that os-specific .h file for GTK instead, to create the GTK version.

So, right now, to compile the GTK version you use one enh_dbg_os_specific.h file (plus some libraries, and extra include files), and to compile with Win32, you simply use the other one. I suspect I should use #ifdefs around two distinct #include statements, for the two different .h files. (But the FINAL final version would have more than just two os-specific .h files!) I have not even chosen the "final" filenames of the two os-specific .h files.

I was certainly hoping to solve at least Brendan's auto-resize infinite loop, and maybe Stevo14's lockups by some workarounds before going any farther toward bochs integration with this GTK version.

But the point is that I always knew integrating this new version into the bochs CVS was not going to be trivial. So I was intending to save that as a separate problem until the actual beta code has been finalized.

And anyway, I have to make a small mod to the enh_dbg.cc file, and one to siminterface.cc -- to deal with jal's issues.

I'm still hoping to hear a little test report from Combuster by the end of the year. At that point, I may give up on testing and go forward with immediate bochs integration with a full CVS patch -- now that quok has demonstrated what it should look like.

I'm also intending to test and post the SDL patch, and to post the untested carbon and rfb patches, very soon.

bewing wrote: I made some enormous modifications from the CVS version, to get to this GTK version. That is, I separated ALL the Win32 code from the "backbone" of the debugger, and put the Win32 code into a separate Win32 OS-specific .h file. Then I rewrote that os-specific .h file for GTK instead, to create the GTK version.

So, right now, to compile the GTK version you use one enh_dbg_os_specific.h file (plus some libraries, and extra include files), and to compile with Win32, you simply use the other one. I suspect I should use #ifdefs around two distinct #include statements, for the two different .h files. (But the FINAL final version would have more than just two os-specific .h files!) I have not even chosen the "final" filenames of the two os-specific .h files.

Since all of that is reflected in my patch, I think that's what may be confusing Stanislav.

I was certainly hoping to solve at least Brendan's auto-resize infinite loop, and maybe Stevo14's lockups by some workarounds before going any farther toward bochs integration with this GTK version.

But the point is that I always knew integrating this new version into the bochs CVS was not going to be trivial. So I was intending to save that as a separate problem until the actual beta code has been finalized.

And anyway, I have to make a small mod to the enh_dbg.cc file, and one to siminterface.cc -- to deal with jal's issues.

I'm still hoping to hear a little test report from Combuster by the end of the year. At that point, I may give up on testing and go forward with immediate bochs integration with a full CVS patch -- now that quok has demonstrated what it should look like.

I'm also intending to test and post the SDL patch, and to post the untested carbon and rfb patches, very soon.

It was actually surprisingly easy to get it to build once I familiarized myself with the layout of the bochs source tree and got all the craploads of GTK+ dependencies straightened out.

bewing wrote:I was also not considering this current beta-version of the GTK frontend to be anywhere near being ready to integrate into bochs, yet.

I made some enormous modifications from the CVS version, to get to this GTK version. That is, I separated ALL the Win32 code from the "backbone" of the debugger, and put the Win32 code into a separate Win32 OS-specific .h file. Then I rewrote that os-specific .h file for GTK instead, to create the GTK version.

So, right now, to compile the GTK version you use one enh_dbg_os_specific.h file (plus some libraries, and extra include files), and to compile with Win32, you simply use the other one. I suspect I should use #ifdefs around two distinct #include statements, for the two different .h files. (But the FINAL final version would have more than just two os-specific .h files!) I have not even chosen the "final" filenames of the two os-specific .h files.

I was certainly hoping to solve at least Brendan's auto-resize infinite loop, and maybe Stevo14's lockups by some workarounds before going any farther toward bochs integration with this GTK version.

But the point is that I always knew integrating this new version into the bochs CVS was not going to be trivial. So I was intending to save that as a separate problem until the actual beta code has been finalized.

And anyway, I have to make a small mod to the enh_dbg.cc file, and one to siminterface.cc -- to deal with jal's issues.

I'm still hoping to hear a little test report from Combuster by the end of the year. At that point, I may give up on testing and go forward with immediate bochs integration with a full CVS patch -- now that quok has demonstrated what it should look like.

I'm also intending to test and post the SDL patch, and to post the untested carbon and rfb patches, very soon.

bewing, you probably not see my point. I will explain you how I see all this.
Let's understand that you trying to build. At the end you will have some cross-platform module for enh debugger interfaces and several OS specific/GUI library specific modules for every host GUI lib possible. And as I understood - the cross-platform module and Win32 part is already supposed to be complete and working and X-Windows specific files are in progress and probably coming soon. This is very excellent and exactly what I dream to see at the end but for now you havily modified original Win32 enh debugger module we have in CVS now and I don't have a way to play with it now. I don't like the idea that I should wait until X-Windows GUI is mature enough BEFORE I start to integrate all this enh debugger infrastucture into Bochs. I want to see the infrastructure in CVS now, with all necessary changes s.t. if you would like to add new GUI library support you just drop-in a new os-specific file, copy-paste few lines inside the Makefile.in and add support to configure.in - nothing more.

It doesn't matter if you prefer to compile enh debugger for each GUI library to separate plugin (similar to current GUI library) or integrate it into particular GUI library plugin - these are only options you could have and you must choose between them !
And definitelly there is no reason to wait until X-windows support is perfectly working BEFORE I can start all this infrastructure intergation. They all could be done in parallel.

Also about next 2.3.8 release. Bochs is going to be presented on one of the boxes in MacWorldExpo 2009 In San Francisco an Jan 5-9 so most likely I would like to release 'what I have in CVS' around that date. We certainly prefer to show 'just released' version instead of 'most recent CVS'. So if X-Windows enh debugger will not ready for that day - no matter - we could release another version in Feb-Mar 2009 if there will be enough content to put in. But I would like to have all the infrstructure in s.t. adding all missing GUIs later will be relatively small work.

So if you could provide me even Win32 only + not working X-Windows enhanced debugger module commented out with 'ifdef 0' - this is exactly that I need now.
I would be able to test NEW Win32 version with NEW intefraces and probably even will find you some issues with X-windows module.

Stanislav

I already DID send you a copy of the current program, with the working win32 OS-specific "drop in" code, 2 weeks ago.
If you would give me a list of the changes you have made to the debugger code you have made in CVS, that will make it much faster for me to integrate your changes into my updated version. Once I have done that, I can send you an updated copy of all the software, through a new copy of quok's patchfile, if you like.

Let's understand that you trying to build. At the end you will have some cross-platform module for enh debugger interfaces and several OS specific/GUI library specific modules for every host GUI lib possible. And as I understood - the cross-platform module and Win32 part is already supposed to be complete and working

It is complete and working, but you said that you wanted to have it TESTED by end users. Have you changed your mind?

The purpose of this X-windows version is to do several things:
It is supposed to test my modifications to x.cc, to begin creating a generic interface between bochs and external debuggers -- a pattern that I can follow to modify sdl.cc, rfb.cc, carbon.cc, the other bochs interfaces, and maybe re-modify win32dialog to follow the pattern, too.

It is supposed to test GTK, a cross-platform portable graphics library that will run on many platforms that do not support Win32.

And it is also supposed to test the base debugger code, that never seemed to get enough testing in the Win32 version.

but for now you havily modified original Win32 enh debugger module we have in CVS now and I don't have a way to play with it now.

Quok's patch works. If you want to compile it as a Win32 version, all you have to do is overwrite the enh_dbg_os_specific.h file with the win32 version that I sent to you, and to overwrite the .rc file with the new one I sent to you. I or Quok will be creating another patch that includes the Win32 and carbon (and perhaps SDL) code also. This will be done in a few days. It would be helpful if I could include any modifications that you have made to the CVS version of the code at the same time.

[quote="bewing"]I already DID send you a copy of the current program, with the working win32 OS-specific "drop in" code, 2 weeks ago.
If you would give me a list of the changes you have made to the debugger code you have made in CVS, that will make it much faster for me to integrate your changes into my updated version. Once I have done that, I can send you an updated copy of all the software, through a new copy of quok's patchfile, if you like.
[quote]

Actually this drop-in wasn't exactly drop-in. I made a few changes into the code to make it working compiling somehow but still can't make it compiling correctly.
My last problem is link error:
gui/libgui.a(win32.o):win32.cc:(.text+0xf9b): undefined reference to `InitDebugDialog(HWND__*)'

Your enh_dbg.cc already doesn't have such a function InitDebugDialog(HWND__*), you have InitDebugDialog(void*) instead so link cannot find it.
win32.cc although has code that I don't know to fix:
What I did in general is - added enh_dbg.cc into the gui folder and to the Makefiles.
Added new file win32_enh_dng_osdep.h, which I would like to convert to win32_enh_dng_osdep.cc a bit later and compile it to plugin, I just want to make sure everything works before I do it.
To make all this stuff compiling I had to make several changes to win32_dialog.cc and enh_dbg.cc in order to fix compilation and link errors.
Now I have smth which more or less drop-in to CVS, up to one link error.

Stanislav

Here is the almost drop-in-to-CVS code that I almost compiled for your reference.
Would appreciate if you fix me the compilation error and enable all your future versions to be based on these changes.

Thanks,

Stanislav

Better late than never. And since Stanislav is around here I'm gonna nag him about some other things as well

I tried the patch on a clean copy of 2.3.7. Patching and compiling worked out as expected, the resulting binary nicely showed the graphical UI when asked.

configured with, amongst others, --with-all-libs (which implies --with-x but also --with-sdl) I set the appropriate directive in the bochsrc to use the X frontend (rather than the SDL frontend which is default in my setup), --enable-all-optimisations, SSE4+extensions+daz, xsave and aes, ne2k and sb16. Would've tried 3dnow support but it gave compilation errors about missing members.

And *lots* of pendantic warnings in enh_gui.cc (courtesy of the -Wall -Wextra)

Host: gentoo linux (x86_64)

The only thing that occurred to me as broken was the panic dialog. By default bochs spurs out a series of bad character height panics (just plain annoying, does not indicate *any* bug and is a regression compared to older versions - please make it an info), but when I pressed the debugger button on the message box it repeated the message instead. The log shows a round of panic,panic,"should not reenter" messages for each popup shown.




As for the general debugger discussion, would it be a better idea to cleanly separate the debugger interfaces from the rendering library. Some things along these lines have already been discussed but it would make it trivial to choose (at configure or runtime) between the GUI and the text interface, and use any supported debugging interface without the display-library specific hacks (e.g. you could pair the GTK debugger with a SDL window on linux, win32 debugger+sdl on windows, or drop in a new QT or network based debugging interface)

Combuster wrote: And *lots* of pendantic warnings in enh_gui.cc (courtesy of the -Wall -Wextra)

Yeah, I know. I'll fix 'em when I get around to it, but it's entirely the fault of ANSI/ISO and their stupid arbitrary non-C compliant "C".

The only thing that occurred to me as broken was the panic dialog. By default bochs spurts out a series of bad character height panics ...

I take it that these are non-fatal "panics"? Do you have a way to get around them, besides just closing each popup?

As for the general debugger discussion, would it be a better idea to cleanly separate the debugger interfaces from the rendering library? Some things along these lines have already been discussed but it would make it trivial to choose (at configure or runtime) between the GUI and the text interface, and use any supported debugging interface without the display-library specific hacks (e.g. you could pair the GTK debugger with a SDL window on linux, win32 debugger+sdl on windows, or drop in a new QT or network based debugging interface)

Yes, it would, in general. The sad thing is that many years ago (2001?), it was decided to build the debugger interface into the "bochs event mechanism". From the bochs end, there are only two links into the external debugger -- the BX_SYNC_EVT_GET_DBG_COMMAND, and BX_ASYNC_EVT_DBG_MSG event messages. The way bochs is designed, all BX_EVENT messages are supposed to be processed by the VGAW rendering library interface function. But the job was left completely unfinished, with only the win32 library interface function being modified to support these two debugger-specific messages (in an unacceptable way). That is why I have to patch all the other ones -- they do not contain any external debugger support at all, in their event handler routines (or debugger initialization support).

But I am trying to move in that direction, yes -- by creating a de facto standardized interface between bochs and the external debuggers, by making all the rendering library interface functions have intentical debugger interfaces. Once all the rendering interface functions have identical code to interface with the external debugger, then hopefully the code can be made independent of the rendering interface functions.

bewing, do you know how to fix the compilation error I get ?

Stanislav

Yes, you just put a (void *) cast on the HWND variable.