> 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.
Some OSes do that to set the VBE video mode, but mine does not do that yet.