Another Alternate GUI for Bochs

[bewing]

The FPU registers are not displayed correcty - the exponent is missing.

In hex, the register is displayed as an MMX register. In decimal, the register is shown as a standard floating point value in a standard floating point format. It is not divided into fraction and exp, because that is not useful.

The SSE registers display is useless.

Yes, we already said that there was an error in FillSSE that you probably commented out, in order to get your code to compile.

And in any case, how does the internal debugger display the SSE registers? How does print_tree display the SSE registers? They are all useless.

- Also please remove debug printf from xnn registers display.

Woops, that was supposed to be an sprintf, not for debugging.

CR2, and MXCSR are not particularly useful registers, and are only displayed in the param_tree. The register list is only a shortcut for registers that might be needed often. The same goes for the FPU.tag & etc.

The code that going to be integrated into CVS for next Bochs release going to based on version I have now.

I think that would be a big mistake. The version you have now does not have param_tree support, it probably does not support SSE properly, it has a bug in the breakpoint code, it has a bug in the docking code, there are too many "magic constants" -- and it does not sound like the dialog window is working for you either. Please try the Physical Dump or Linear Dump commands to see if you get a dialog box -- as well as double-clicking on a GP register. In other words, I would say that the version you have does not completely work. I have also added one more feature.

I sent it to you for testing purposes, not to be the final integrated code, but you can do as you wish.

I can merge my new version together with your changes very quickly. BTW, I think it is highly unreasonable of you to be making an issue of minor style differences. Traditional C-style bracket indentation is not necessarily superior, and the Bochs Code Guidelines do not say that it is needed, at all.

In any case, I will be posting a new version of my debugger here for the #osdev users, with all the current changes, within the next few days -- whether you want to see the new code or not. It is WindowsNT who cares if there are multiple versions of this debugger ... not me.

[stlw]

The FPU registers are not displayed correcty - the exponent is missing.

In hex, the register is displayed as an MMX register. In decimal, the register is shown as a standard floating point value in a standard floating point format. It is not divided into fraction and exp, because that is not useful.

The SSE registers display is useless.

Yes, we already said that there was an error in FillSSE that you probably commented out, in order to get your code to compile.

And in any case, how does the internal debugger display the SSE registers? How does print_tree display the SSE registers? They are all useless.

- Also please remove debug printf from xnn registers display.

Woops, that was supposed to be an sprintf, not for debugging.

CR2, and MXCSR are not particularly useful registers, and are only displayed in the param_tree. The register list is only a shortcut for registers that might be needed often. The same goes for the FPU.tag & etc.

The code that going to be integrated into CVS for next Bochs release going to based on version I have now.

I think that would be a big mistake. The version you have now does not have param_tree support, it probably does not support SSE properly, it has a bug in the breakpoint code, it has a bug in the docking code, there are too many "magic constants" -- and it does not sound like the dialog window is working for you either. Please try the Physical Dump or Linear Dump commands to see if you get a dialog box -- as well as double-clicking on a GP register. In other words, I would say that the version you have does not completely work. I have also added one more feature.

I sent it to you for testing purposes, not to be the final integrated code, but you can do as you wish.

I can merge my new version together with your changes very quickly. BTW, I think it is highly unreasonable of you to be making an issue of minor style differences. Traditional C-style bracket indentation is not necessarily superior, and the Bochs Code Guidelines do not say that it is needed, at all.

In any case, I will be posting a new version of my debugger here for the #osdev users, with all the current changes, within the next few days -- whether you want to see the new code or not. It is WindowsNT who cares if there are multiple versions of this debugger ... not me.

The XMM and FPU debug prints are very useful. At least for me. I use them really frequently. As one of the people who understand the black magic of RAW floating point numbers I prefer to see them together with converted value. If you want to see how the XMM registers are printed - try 'xmm' command in the debugger.

About all the rest - if you have a version which doesn't add any logic mess that you was talking about here (threading, stooping one CPU a letting others to run and etc), not going away from portability (by using new STL-based structures or threads) - I don't mind to wait a bit until your new version be posted. This is actually meeans "will be based on current sources" i.e. "on current interfaces". I hope you finally undestand ...

Stanislav

[bewing]

** Updated version available **
It's New! It's Improved! It's Easy! Everyone should try it! (At least, everyone who uses Bochs on Windows.)

See the very first post on this thread (or the third post) for the "patches" to Bochs 2.3.7

New features: Multi-CPU support, bochs param_tree support, Stack view. A few bug fixes. Maybe some speed improvement.

Stanislav: see your emailbox here on osdev for your copy. If anyone else should happen to want a patch to the CVS snapshot, just say so.

[stlw]

** Updated version available **
It's New! It's Improved! It's Easy! Everyone should try it! (At least, everyone who uses Bochs on Windows.)

See the very first post on this thread (or the third post) for the "patches" to Bochs 2.3.7

New features: Multi-CPU support, bochs param_tree support, Stack view. A few bug fixes. Maybe some speed improvement.

Stanislav: see your emailbox here on osdev for your copy. If anyone else should happen to want a patch to the CVS snapshot, just say so.

WOW, very impressive !
The param tree window on the side just fantastic. But little bit looks weird because it is not sorted.
I would expect to see registers sorted in cpu0 and etc. Is it Bochs problem or problem of your way of building the tree for display ?

But still I see a few more issues. Let me enumerate them.

- FPU registers are not displayed completely. I still would like to see EXP field added (you show only MMX which is aliased to FPU fraction but FPU exp isn't shown).
Also FPU control word and FPU status word are very useful.

- The biggest issue for me - I didn't manage to make it working in 64-bit mode. Looks like you didn't catch BX_SUPPORT_X86_64 correctly.
When you are in 64-bit mode nothing is displayed in disasm window, all the registers are still 32-bit and etc.
Stack printed accrding to ESP and not according to RSP.

- I played with 'Break on CPU mode change' and in most cases seen that CPU mode is not displayed correctly in status bar.
I break into protected mode and status bar shows me read mode, sometimes wise versa. Never seen long mode there
The current CPU mode string you could get using cpu_mode_string function. It receives as paramtered a mode returned by get_cpu_mode method.
Just use it to update status bar

- The option 'Text in UPPERCASE' doesn't affect disasm. I would prefer to see it in lower case. Disassember returns text in low case so you especially converts it to upper case.
Just connect the conversion to 'Text in UPPERCASE' option.

- Page Table printed is a bit strange. At least I don't understand what is printed. It supposed to be lin : physical for all pages but instead I see a lot of duplicate lines with no meaning.
Is it Bochs output wrong and you taking it 'as is' ?

More complains will come later

Thanks,
Stanislav

[bewing]

But little bit looks weird because it is not sorted.

It is sorted alphabetically. If you can guarantee for me that the bx_list::get function will always return items in an "intelligently sorted" order, then I will turn off the alphabetic sort.

- FPU registers are not displayed completely. I still would like to see EXP field added (you show only MMX which is aliased to FPU fraction but FPU exp isn't shown).
Also FPU control word and FPU status word are very useful.

I think you are the only person in the whole world who uses those register values often. You are free to customize your own copy. But I really do not think those values are useful for anyone but you. They are bochs internal values -- or hidden values that are inaccessible inside the CPU chip. They are available inside the param_tree. I don't see why this isn't enough. If *I* am programming the FPU, all I want to know is the floating point value in each STi register.

- The biggest issue for me - I didn't manage to make it working in 64-bit mode. Looks like you didn't catch BX_SUPPORT_X86_64 correctly.

The code to detect Long Mode is in my OnBreak() function. I tested it, and it seems to work in my compiler -- which seems to mean that it is a compiler issue.
My OS is not 64bit, so I have a hard time testing 64bit functionality, but are you sure you compiled your test version of bochs with 64bit support? If you look at the param tree, does your cpu_mode variable show a value of 4, when my frontend is not displaying a "Long Mode" status?

This debugger always is in 64bit mode, and does not use the BX_SUPPORT_X86_64 #define at all.

I emailed you a test file -- perhaps it might fix the problem.

- I played with 'Break on CPU mode change' and in most cases seen that CPU mode is not displayed correctly in status bar.

Try doing a singlestep. When you are in Real Mode, bochs breaks JUST BEFORE changing to PMode. One step later, it will switch. Bochs really is still in Real mode, when it breaks.

- The option 'Text in UPPERCASE' doesn't affect disasm. I would prefer to see it in lower case. Disassember returns text in low case so you especially converts it to upper case.
Just connect the conversion to 'Text in UPPERCASE' option.

The disassembly screen does not refresh automatically. Hit the refresh button, and the case will change. But I think you will find that it is harder to read in lowercase, unless you also switch to a fixed font.

- Page Table printed is a bit strange. At least I don't understand what is printed. It supposed to be lin : physical for all pages but instead I see a lot of duplicate lines with no meaning.
Is it Bochs output wrong and you taking it 'as is' ?

I copied the code DIRECTLY out of bochs. If you do a 'info tab' command to the Internal Debugger, you should see EXACTLY the same display. I agree that it looks funny. Maybe I have another bug, or maybe the code in bochs is wrong, too.

[stlw]

But little bit looks weird because it is not sorted.

It is sorted alphabetically. If you can guarantee for me that the bx_list::get function will always return items in an "intelligently sorted" order, then I will turn off the alphabetic sort.

Yes, turn off the automatic sorting. I fully control we order list::get returns you a values - this is the order defined when building the tree.
At least in CPU the order is much more reasonable than one you have.
As example see agaoin how in main.cc function print_tree prints the tree. It could be see from debugger as well - using a command 'show "cpu0"'.

BTW, while playing with it see some very annoying issue with command line EditBox -
- It doesn't support simple edit box buttons like Home or End (go to beginning of the line or end of the line)
- Sometimes it somehow 'locks' and I get type anything at all, I even visually EditBox somehow changes, like it has more than single line but only one line is displayed.
I could fix this by pressing Enter several times but the issue happens too often.
Also for debugger outpput bar:
- Try 'show "."', it prints you a whole param tree and it is long enough to confuse your output window
- Scroller disappears, the window locks and doesn't show anything anymore. I can't see what it was even
- Try 'show "CS"' command many many times. After some amount of times the window just disconnects, i.e. the scroller is still there and I even can scroll but I can't
see anything new in the windows. Commands are still executed correctly - I see them in debugger_log.

I think you are the only person in the whole world who uses those register values often. You are free to customize your own copy. But I really do not think those values are useful for anyone but you. They are bochs internal values -- or hidden values that are inaccessible inside the CPU chip. They are available inside the param_tree. I don't see why this isn't enough. If *I* am programming the FPU, all I want to know is the floating point value in each STi register.

Yeah, just because I am working on CPU architecture. They ARE architectural, you see the exponent if you doing FSAVE or even simple FSTP instruction.
And sometimes it is useful to know what kind of special FP number you have - NaN, INF, Denormal ? All this you see on expomnent.
And also - my own copy is a CVS copy, so I will add this into CVS now or later anyway

The code to detect Long Mode is in my OnBreak() function. I tested it, and it seems to work in my compiler -- which seems to mean that it is a compiler issue.
My OS is not 64bit, so I have a hard time testing 64bit functionality, but are you sure you compiled your test version of bochs with 64bit support? If you look at the param tree, does your cpu_mode variable show a value of 4, when my frontend is not displaying a "Long Mode" status?

This debugger always is in 64bit mode, and does not use the BX_SUPPORT_X86_64 #define at all.

This means you ALWAYS should print 64-bit registers in the regs display window on the left side ?
I never seen them there. It is easy to check - go to http://www.menuetos.net/ and download yourself 64-bit enabled OS floppy image.
I one minute you could boot it and see how it looks like.

Your test file isn't related to this bug - I don't see how it could affect anything, it is the same written in a bit different construction.
I tried add #error is BX_SUPPORT_X86_64 == 0 but it didn't fail so I have BX_SUPPORT_X86_64 compiled inside ...

- I played with 'Break on CPU mode change' and in most cases seen that CPU mode is not displayed correctly in status bar.

Try doing a singlestep. When you are in Real Mode, bochs breaks JUST BEFORE changing to PMode. One step later, it will switch. Bochs really is still in Real mode, when it breaks.

I know something else and sure I know better because I wrote it
Mode Change break you immediatelly AFTER you change a mode. It prints in debugger window:
Caught mode switch breakpoint switching to 'protected mode'
This 'protected mode' is new current mode. You could see the mode also by looking on CR0 register - PE bit is set and it still shows "REAL MODE".
Single step doesn't help, I can do 10 times single step INSIDE protected mode and it will still print "REAL MODE" in status bar.
The same with long mode - I never seen long mode printed there as well.

Also one small complain about the code - you write:

Code: Select all

            len = bx_disassemble.disasm(InPMode, In64Mode, (bx_address) 0, (bx_address) LAddr, (Bit8u *) p, tmpcf);

The first param doesn't mean in inPMode, it means in 32-bit mode. Real mode could be 32-bit and protected mode could be 16-bit, the mode defined only by CS.D_B bit.
It looks like the things are handled correctly in general case but I not sure that nobody nowhere was mistaken by wrong varaible name and misused/misassigned it.

Code: Select all

The disassembly screen does not refresh automatically. Hit the refresh button, and the case will change. But I think you will find that it is harder to read in lowercase, unless you also switch to a fixed font.

Thanks, it helped
But registers window does refresh automatically, so why don't refresh the disasm window as well - at least when UPPERCASE menu is choosen ?

Also pay attention - the mode-break button doesn't work (have no effect) when CPU is running. I suggest you to disable all menus as well when you running.
Only one button option should be available - stop by pressing ctrl-c.

Stanislav

[stlw]

- Page Table printed is a bit strange. At least I don't understand what is printed. It supposed to be lin : physical for all pages but instead I see a lot of duplicate lines with no meaning.
Is it Bochs output wrong and you taking it 'as is' ?

I copied the code DIRECTLY out of bochs. If you do a 'info tab' command to the Internal Debugger, you should see EXACTLY the same display. I agree that it looks funny. Maybe I have another bug, or maybe the code in bochs is wrong, too.

I understood what is the problem here !
Typical 'info tab' dump looks like:

Code: Select all

    0xc0257000-0xc0257fff -> 0x006fa000-0x006fafff

This means linear range -> physical range. You cut off the first pair and the '->' and got only second pair which has no meaning alone.
Put it back, please

And some wish list for the end:

- You know to show GDT and IDT. How about LDT ? Bochs CVS supports it.
- When command EditBox contains nothing and I press Enter (usually by mistake or fix an issue that it 'stuck') the CPU makes single step.
I prefer to do NOTHING. The single step shortcut would be 's'.
- BTW, disasm window is refreshed automatically when you toggle Intel<->AT&T syntax, so UPPERCASE button shouldn't be hard
- Do not forget that in 64-bit mode linear address (and soon hopefully also physical address) could be 64-bit wide !
It seems like L.Address field in Linear/Physical dump would not support it.
The the same problem with 640bit disassembler in 64-bit mode. Looks like you store LIP (linear IP) in 64-bit mode into 32-bit value and lose upper 32-bit.
As result you going to disassemble wrong addresses.
- In left registers window you show debug registers re-numbered. DR7 become DR5 for example. Not a big deal but better to give them their real names.
- Give me my CR2 value
- BTW, XMMs I see all 15 registers (although XMM8-XMM15 not available in legacy mode) but I don't see R8-R15 even in long mode. I think it is a bug !
- How about SMP ? How I switch between the logical processors ?

Thanks,
Stanislav

[bewing]

> Yes, turn off the automatic sorting

OK. It's off.

> see some very annoying issue with command line EditBox
> - It doesn't support simple edit box buttons like Home or End

I will look at that, and see how hard it is.

> - Sometimes it somehow 'locks'

At the bottom of user_man.txt, I say specifically that I know about this bug. It is very hard to fix. It happens when the debugger window gets "hidden" behind another window, or minimized. Then you cannot type into the window, until you CLICK on any part of the window.
If you see it happen at any other time, then please give me an exact set of actions, so I can duplicate the error.

> Output window: - Scroller disappears, the window locks

OK, I will look at this and fix it.

> All this you see on exponent.
Standard floating point format (which I already show) should also show NaN and +/-INF. Maybe denormal, too.

> You cut off the first pair and the '->'

OK, fixed.

> This means you ALWAYS should print 64-bit registers in the regs display window on the left side ?

No, it means that I test if cpu_mode == 4, and then make the column wide enough for 64bit printing, and show 64 bits.

> Your test file isn't related to this bug - I don't see how it could affect anything, it is the same written in a bit different construction.

As I said, the LongMode test WORKED on my machine. I also do not see anyone else here reporting any problems with it. Since it doesn't work on yours, it seems to be a compiler problem. Compiler problems are solved by writing code with a different construction. But it might also be a difference between release 2.3.7 and the CVS snapshot. I will look at that.
I will also get the menuet and try it.

> Mode Change break you immediatelly AFTER you change a mode. It prints in debugger window:
> Caught mode switch breakpoint switching to 'protected mode'

Switching from RealMode to Pmode takes TWO steps. A CR0 change and then a far JMP. Bochs breaks after the CR0 change. But the CPU is still in RealMode until it actually takes the far JMP. If you look at the ASM display on a CPU Mode break from Real to Pmode, you will see that the sim stopped on the far JMP.

But it now sounds like my frontend is having a hard time reading your bx_cpu.cpu_mode variable, perhaps. I will try debugging the CVS snapshot, and see if cpu_mode is working differently now.

> the mode defined only by CS.D_B bit.

That is the bit that I use for the 'InPmode' variable. Perhaps when WindowsNT named that variable, it was not the best choice, but I think it is good enough. The real meaning of it is "Not in 16bit mode". Exactly as the d_b bit specifies.

> But registers window does refresh automatically, so why don't refresh the disasm window as well - at least when UPPERCASE menu is choosen ?

Because the Register window is designed to only contain a very small amount of data! So it is very fast to refresh. The ASM window can contain several thousand lines of disassembly (and the third window can also contain many thousand lines). So it is reasonable to automatically refresh the Register window, but not the other two. This also means that it is important not to fill up the Register window with every possible thing that you could ever want to see. The Register window should never grow to be much bigger than one screenful.
When a window gets refreshed, all the old data must be thrown away, and completely reloaded.

> the mode-break button doesn't work (have no effect) when CPU is running

Are you sure? It should work fine. Disabling menus is not fun. I have to disable every single item on them separately. Then re-enable all of them. Everyone who uses bochs in disassembly mode is a programmer, and I think they will all understand what might cause problems. Many commands (especially on the Options menu) should work fine while the sim is running.

> How about LDT?

Nobody uses LDTs anymore, so it is a waste of time and code.

> CPU makes single step. I prefer to do NOTHING.

Ha! Too bad! I prefer singlestep. That is how my other favorite debugger works.
'S' is a printable character, and therefore cannot be used for any sort of shortcut.

> - Do not forget that in 64-bit mode linear address (and soon hopefully also physical address) could be 64-bit wide !
> It seems like L.Address field in Linear/Physical dump would not support it.

Yes, all windows fully support it. All column widths adjust when cpu_mode == 4.

> As result you going to disassemble wrong addresses.

I don't think so. All address variables are 64bit.

> - In left registers window you show debug registers re-numbered. DR7 become DR5 for example. Not a big deal but better to give them their real names.

Oops. Forgot to fix DR6 and 7. Fixed now.

> I don't see R8-R15 even in long mode.

R8 - R15 will show up automatically when cpu_mode == 4 is detected.

> - How about SMP ? How I switch between the logical processors ?

When

Code: Select all

 			TotCPUs = SIM->get_param_num(BXPN_CPU_NPROCESSORS)->get() *
				     SIM->get_param_num(BXPN_CPU_NCORES)->get() *
					 SIM->get_param_num(BXPN_CPU_NTHREADS)->get();

is > 1, then a row of buttons will appear for you to switch between displaying each CPU.

-- and why do you want CR2? The very first thing anyone does with CR2 (when it is valid) is to copy it into a GP register. So you should already know its value.

[stlw]

I think found a problem with 64=bit mode detection !

You have:

Code: Select all

    // then detect current CPU mode the *right* way -- look for changes
    // TODO: create param Objects for CS.d_b for each CPU
    i = BX_CPU(CurrentCPU)->sregs[BX_SEG_REG_CS].cache.u.segment.d_b;
    if (i == 0)     // in Real Mode?
    {
        if (InPMode != FALSE)
            CpuModeChange = TRUE;   // is that a mode change?
        InPMode = FALSE;
        In64Mode = FALSE;
    }
    else        // no, cpu is either in Pmode or Long mode
    {
        if (InPMode == FALSE)
            CpuModeChange = TRUE;
        InPMode = TRUE;
    // TODO: create param Objects for mode for each CPU
        i =BX_CPU(CurrentCPU)->get_cpu_mode();
        bx_bool j = (i == BX_MODE_LONG_64);
        if (j != In64Mode)              // change in Long Mode status?
        {
            CpuModeChange = TRUE;
            In64Mode = j;
            ResizeColmns = TRUE;        // if so, some formatting has changed
            StackSized = 0;
        }
    }

In 64-bit mode it is ALWAYS CS.L = 1, CS.D_B = 0 (CS.L = 1, CS.D_B = 1 is reserved combindation and will #GP).
So if you are in 64-bit mode CS.D_B = 0 and you fall into 'in Real Mode?' statement and because of 'else' statement later never check for 64-bit anymore.
The order of checks must be changed !
And please, rename InPMode, give it a name In32BMode for example - this will help to avoid future confusion.

Waiting for your new version soon !

Thanks,
Stanislav

[stlw]

> Your test file isn't related to this bug - I don't see how it could affect anything, it is the same written in a bit different construction.

As I said, the LongMode test WORKED on my machine. I also do not see anyone else here reporting any problems with it. Since it doesn't work on yours, it seems to be a compiler problem. Compiler problems are solved by writing code with a different construction. But it might also be a difference between release 2.3.7 and the CVS snapshot. I will look at that. I will also get the menuet and try it.

Almost nobody here plays with 64-bit, own 64-bit OS is for advanced developers

Switching from RealMode to Pmode takes TWO steps. A CR0 change and then a far JMP. Bochs breaks after the CR0 change. But the CPU is still in RealMode until it actually takes the far JMP. If you look at the ASM display on a CPU Mode break from Real to Pmode, you will see that the sim stopped on the far JMP.

But it now sounds like my frontend is having a hard time reading your bx_cpu.cpu_mode variable, perhaps. I will try debugging the CVS snapshot, and see if cpu_mode is working differently now.

Yes, you are right, in real hardware CPU it is.
But Bochs is lazy, switch from pmode to real mode and back happens with CR0 write on Bochs. Once you set CR0.PE you are in protected mode.
Far jump only needed to switch between 16-bit and 32-bit or between compatibility mode and long mode.

> But registers window does refresh automatically, so why don't refresh the disasm window as well - at least when UPPERCASE menu is choosen ?

Because the Register window is designed to only contain a very small amount of data! So it is very fast to refresh. The ASM window can contain several thousand lines of disassembly (and the third window can also contain many thousand lines). So it is reasonable to automatically refresh the Register window, but not the other two. This also means that it is important not to fill up the Register window with every possible thing that you could ever want to see. The Register window should never grow to be much bigger than one screenful.
When a window gets refreshed, all the old data must be thrown away, and completely reloaded.

I know. But how often user toggles UPPERCASE menu option ?

> the mode-break button doesn't work (have no effect) when CPU is running
Are you sure? It should work fine. Disabling menus is not fun. I have to disable every single item on them separately. Then re-enable all of them. Everyone who uses bochs in disassembly mode is a programmer, and I think they will all understand what might cause problems. Many commands (especially on the Options menu) should work fine while the sim is running.

Almost sure. Try it. Toggle the menu option when emulation is running and see if it will stop.

> How about LDT?
Nobody uses LDTs anymore, so it is a waste of time and code.

OK.

> CPU makes single step. I prefer to do NOTHING.

Ha! Too bad! I prefer singlestep. That is how my other favorite debugger works.
'S' is a printable character, and therefore cannot be used for any sort of shortcut.

OK. But I will check how my favorite debugger behaves

> - How about SMP ? How I switch between the logical processors ?

When

Code: Select all

 			TotCPUs = SIM->get_param_num(BXPN_CPU_NPROCESSORS)->get() *
				     SIM->get_param_num(BXPN_CPU_NCORES)->get() *
					 SIM->get_param_num(BXPN_CPU_NTHREADS)->get();

is > 1, then a row of buttons will appear for you to switch between displaying each CPU.

BTW, instead of calculating the TotCPUs you could use macro BX_SMP_PROCESSORS. It is global variable eq to TotCPUs when SMP is compiled in and constant = 1 when SMP is disabled.

Stanislav

[bewing]

OK, some fixes are in your mailbox.

The BX_SMP_PROCESSORS macro is only available if you have bochs.h included. I am trying to stop including bochs.h and cpu.h -- only siminterface.h. In a future version, you could move/copy the macro into siminterface.h.

> Try it. Toggle the menu option when emulation is running and see if it will stop.

I will have to create an OS that switches back and forth from Real to Pmode, with a delay, first. Some OSes do that to set the VBE video mode, but mine does not do that yet.

> But Bochs is lazy, switch from pmode to real mode and back happens with CR0 write on Bochs.

But this debugger is not lazy, and only shows the change to PMode after the far jump is complete.

-----
Oops, I got DR7 renamed, but not DR6. I have fixed it now, but you will need to pretend that it is fixed in the version in your mailbox. I will send another version with more fixes in a few hours.

[stlw]

Oops, I got DR7 renamed, but not DR6. I have fixed it now, but you will need to pretend that it is fixed in the version in your mailbox. I will send another version with more fixes in a few hours.

Some fixes from me as well - see the patch.
It contains a few small fixes:

1. Compilation error fix under cygwin 'fp.fraction*scale_factor' is undefined variable.
2. I fixed DR6 by myself
3. Removed a dot after decimal value printed on the registers dump window - annoying me a bit
4. Completely rewrote your part of code which detects CpuModeChange and assigns values to In64Mode and In32Mode.
Support priting in status bar info about ANY mode, including v8086 and compat mode, also differ between 16/32.
I think it useful info, it helps to understand what is the default mode in disasm!
5. Removed some redundant code.

Stanislav

P.S> 64 bit is working now, I like it !
Just one question - why 32-bit GP regsiters are still printed in 64-bit mode and why XMM8-XMM15 printed in legacy mode ?
Anyway - we could think about starting thee integration into Bochs CVS, what do you think ?
How many changes do you plan still ?

[stlw]

The BX_SMP_PROCESSORS macro is only available if you have bochs.h included. I am trying to stop including bochs.h and cpu.h -- only siminterface.h. In a future version, you could move/copy the macro into siminterface.h.

Just did. In CVS version.

> Try it. Toggle the menu option when emulation is running and see if it will stop.

I will have to create an OS that switches back and forth from Real to Pmode, with a delay, first. Some OSes do that to set the VBE video mode, but mine does not do that yet.

For me this is not a problem at all. I have bunch of Win98 and WinXP images - Microsoft sooo likes to do this crap
And I spent too much time analysing their OS code through Bochs.

> But Bochs is lazy, switch from pmode to real mode and back happens with CR0 write on Bochs.

But this debugger is not lazy, and only shows the change to PMode after the far jump is complete.

Really? This works fine as I wanted after my change. Just a bit more work in OnBreak method.

Stanislav

[bewing]

I will look at your changes.

The only changes I was still intending to make are the fix for the Output window overflow (I just figured out the problem) and adding support back in for left/right arrow, and home/end in the keyboard Input window.

The dot in the register window is a traditional indication that the value is in decimal (ie. base 10). But I don't care very much whether it is there or not. I am just saying that I *did* put it there for a reason.

Just one question - why 32-bit GP regsiters are still printed in 64-bit mode

If you are in 64 bit mode, and you do a MOV EAX, [mem] -- you might want to know what value you are moving. If you are interested in the decimal value of the 32bit version of the register, it is interesting. 32bit register values are used often in 64bit mode. You can turn off showing the 32bit registers in the Options menu.

and why XMM8-XMM15 printed in legacy mode?

Because I wasn't sure if you could access those last 8 registers in legacy mode or not. It's trivial to put an 'if' around it if you think I should. I don't use SSE yet in my OS, so I don't know.

[stlw]

I just merged your debugger into Bochs CVS code. It compiles and works fine for me for now.
So any next enhancement or bug fix should be already a patch for Bochs CVS tree.
Do you like to have CVS write access to simplify things ?

I also suggest you would open another thread in the forum and ask others to start working with the debugger regularly and see their complains.
I would like to see peoples feedback and fix all major issues (if they are) before we issue official next Bochs release.

So you are welcome to download Bochs CVS sources and take a look. BTW, I changed the win32_enh_dbg.h to be .cc file, modified all the Makefiles and configure script, might be MSDEV workspaces should be modified as well.

Stanislav