OSDev.org

bewing wrote:I have taken the Bochs GUI frontend for windows that was created by WindowsNT, and posted on this thread -- and modified it quite a bit to suit my tastes.
It has different commands, more options, different menus, a slightly different look, extra features, and should be faster.

So, this is a formal test request for my beta version (0.3). The download on this post contains (very easy) instructions for hand-patching the code into bochs -- it should be compatible with any bochs ver 2.3.X -- I hope.

If you patch it into a different version than 2.3.7, I would be esepcially interested to hear how it goes.

In a few hours (as soon as I can take a nap and then figure out how to do it ... ) I will post another copy that does the patch automatically into bochs 2.3.7 (especially for Stanislav to play with).

This version still has the ability to interact with the "internal bochs textmode debugger" -- to issue the commands that you all are familiar with. Within a week or so, I will be posting a version that completely replaces the bochs internal debugger.

Could you explain what is the problem with it for you?

1) If I get rid of the internal debugger, I don't need the space at the bottom of the screen for the Input and Output windows. This leaves more room for important things, and simplifies the design of my program.

2) The current bochs internal debugger is inefficient. For example, the watchpoint and breakpoint lists are not sorted. If they were sorted (and the algorithm made use of the fact that they were sorted), it would speed up the simulation a lot.

Also, the handling of the memory callbacks is not as efficient as it should be -- and the "if" is backwards, so the watchpoints don't work correctly anyway.

3) I don't need the internal debugger anymore. It is just a barrier between me and the sim. You have been pointing out how a debugger can control the sim directly. I am intending to do exactly what you have said.

6) The internal debugger does not provide a good interface between me and the sim for running a multiple CPU simulation, where all the CPUs are running simultaneously.

For example, if I was controlling the sim directly, then I could have a multi-threaded debugger, controlling the simulation of each CPU with a different thread, simultaneously. I cannot do that through the internal debugger.

7) The current internal debugger is not stateless, as far as I can tell. So I have to always keep its state consistent, even though I am not really using it anymore, except to singlestep the sim.

The way that the internal debugger informs me of breaks in the simulation is kludgy and stinks. The way that it informs me that it is ready to process another command is also kludgy.

But until your debuger has ALL that internal debugger has (including save/restore support and work with param treee) + will suit for all Bochs' usages (x86-64 support, smp support) - it will not become default replace for internal debugger.

You write the debugger trying to follow Bochs coding guidelines

I want to make currrent debugger compatible with this inetrface and working.
Your suggestions?

bewing wrote: ...and the "if" is backwards, so the watchpoints don't work correctly anyway.

This I can't understand. As far as I know the watchpoints work correctly everywhere.

      if (write_watchpoint[i] <= phy && write_watchpoint[i] + len > phy) {

      if (write_watchpoint[i] >= phy && write_watchpoint[i] < phy + len ) {

#if BX_SUPPORT_A20
#  define A20ADDR(x)                (bx_phy_address(x) & bx_pc_system.a20_mask)
#else
#  define A20ADDR(x)                (bx_phy_address(x))
#endif

#if BX_SUPPORT_A20
#  define A20ADDR(x)                ((bx_phy_address)(x) & bx_pc_system.a20_mask)
#else
#  define A20ADDR(x)                ((bx_phy_address)(x))
#endif

Also if you hav some suggestions for making it more efficient - I am open for ideas.

	bx_address h = CurrentAddress;
	int j= BreakCount;
	while (--j >= 0)			// loop over all breakpoints
	{
		// brk list is sorted -- if the value goes too low, end the loop
		if (BrkLAddr[j] < h)
			j = 0;		// force the loop to end if it goes too far -- no breakpoint match
		else if (BrkLAddr[j] == h){
			j = 0;
			break!	// hit a breakpoint
		}
	}

	mov ecx, [BreakCount]
.brklp:
	dec ecx
	jl short .done
	mov eax, [h]
	cmp [BrkLAddr + ecx*4], eax
	jge short .tste
	xor ecx, ecx		; kill the loop
	jmp short .brklp
.tste:	jne short .brklp
	break!			; hit a breakpoint
.done:

	int j= BreakCount;
	while (--j >= 0)			// loop over all breakpoints
	{
		// brk list is sorted -- if the value goes too low, end the loop
		register breakpt_address i = BrkLAddr[j] - h;		// precalculate the comparison
		if (i < 0)
			j = 0;		// force the loop to end if it goes too far -- no breakpoint match
		else if (i == 0){
			j = 0;
			break!	// hit a breakpoint
		}
	}

bewing wrote:bochs is going to be the slowest emulator ever seen.

bewing wrote:Bochs is good enough for me ... now, if it just had a nice GUI frontend ....

I already have full 64 bit compatibility. By the end of this week, I will have better SMP and param_tree support than the current internal debugger has.
So the question is whether I can figure out how the internal debugger is preventing me from having really good SMP support. Because right now, if I bypass the internal debugger and call cpu_loop(0) from "the wrong thread", then cpu_loop crashes.

As far as save/restore goes: there is no documentation on this, so it will be hard to do. How does it work? What do I need to do to support it? What needs to be saved and restored?

The problem is: the current internal debugger interface is single-threaded, and is not thread-safe.
The sim also assumes that it is single-threaded.
There are places where it tests SIM->is_sim_thread() -- this will need to be eliminated. The CPU code is probably already thread-safe, except that it currently expects to ONLY be called from the single debugger/sim thread.

Probably the easiest and best way to "patch" this (so it continues to work with everything), is to use a registered callback inside the bx_dbg_user_input_loop() function. That way, I can change it from accessing the current sleep loop, and have it call MY input function synchronously, when it wants input.
This would also serve as a flag that the simulation was at a break.
I will write an example, and see if I can get you and WindowsNT to agree to it.

Errors I have seen so far in the bochs code: [skipped]

And if I had lots of time, I'd completely rewrite your param tree interface for you. If you put everything into the param tree, the way it is built right now, bochs is going to be one of the slowest emulators ever seen.

Brynet-Inc wrote:Bochs is an emulator, not a "Virtualizer", it's also very portable.. runs on a wide range of architectures and operating systems.

If you want something open source, decent.. and fast.. try QEMU.

Bochs running every CPU one after another, quantum of instructions on every logical CPU and when advance a timers in one shot after all CPUs are done with the quantum.

No, the problem is bigger. Bochs CPU and devices are single-threaded and not thread-safe !

Yes, I mostly agree with that. The CVS thing is mostly a problem because
1) I don't have it installed, and have never used it.
2) Most of the users here do not use the latest CVS snapshot of bochs -- they use the public releases. So if I create a patch for the CVS version, nobody here can use it.

So, if I create patches for the CVS version, they will only be for you, and I should send them to you directly.

Bochs running every CPU one after another, quantum of instructions on every logical CPU and when advance a timers in one shot after all CPUs are done with the quantum.

Yes, and this is exactly what I would like to fix next. I understand that you will not want to integrate it immediately into bochs. If I make the fix now, and you integrate it into bochs 6 months from now, that is OK with me.

I would certainly like to get some testing done on the current frontend that I've built, on many platforms -- but my test request here on osdev isn't getting much feedback. I hope that is a good sign that nobody is having problems, but who knows!

But that does not mean that I can't be writing new things, for future release, while people are testing what I've done so far.

No, the problem is bigger. Bochs CPU and devices are single-threaded and not thread-safe !

I understand that they are not, currently. However -- I don't see any reason why CPU is not, since all the simulated cpus are already independent, and instruction simulations all seem to be stateless. And the devices all need locks. The problem is the way that time is simulated, as I see it

Would be nice to know how. Do you have any ideas you could share ?