OSDev.org

bewing wrote:

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

Any function/module/method that needs to be atomic, and cannot be made stateless, needs a lock. It seems quite simple to me. Since we are working with a maximum of 8 concurrent threads/CPUs, the lock will probably be quite simple. As far as I know, the current memory routines are also basically stateless. Yes, two cpus can read or write the memory at the same time, in multi-threaded cpu_loops. That is exactly how a multi-CPU real-world machine works, too.

stlw wrote: and if you think you need ANY modification in Bochs CPU - you just ask and get them.

bewing wrote: OK, I would like to make a change. Let's see if we can agree on it.

bx_guard.interrupt_requested is causing me problems because it is not cpu-specific.

The variable is not really needed. I would like to remove it completely from bochs.
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
does exactly the same thing, and it is cpu-specific.

The iodebug.cpp routines that set bx_guard.interrupt_requested directly should all call bx_debug_break() instead.

In those cases where all the CPUs need to be forced to break (on a real or fake control-C), or where the cpu number is unknown, bochs can simply loop over all BX_SMP_PROCESSORS.

I would also like the cpu number to be passed to bx_debug_break() as an argument. Maybe the stop reason should be passed, too.

bewing wrote: 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.

I prefer usage of defines/enums everywhere. According to my opinion each entry of rV array MUST be accessed using define.

The same for magic switch constants in switch(LW) in WM_COMMAND handle.

The line
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
alone doesn't do anything do Bochs, it is just do supply a reason of the break into debugger. The reason is Ctrl-C.
The thing that actually do the break into debugger is bx_guard.interrupt_requested.

When you break into debugger you should have control over all the stuff and not over single CPU.

BTW, I am inteersting which kind of usage model you see for such multi-threaded debugger where every CPU debugged in separate thread and run in separate thread.
I see only complete mess here.

bewing wrote:Try adding a #define _WIN32_IE 0x0400
to the top of the file. Then please recompile and post a new list of errors.

bewing wrote:

The line
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
alone doesn't do anything do Bochs, it is just do supply a reason of the break into debugger. The reason is Ctrl-C.
The thing that actually do the break into debugger is bx_guard.interrupt_requested.

The internal debugger is already using BX_CPU(cpu)->guard_found.guard_found as a stop code. When, for example, the CPU->mode_break detects a mode change, it ends up setting BOTH -- then cpu.cpp detects bx_guard.interrupt_requested and does a break, and dbg_main detects guard_found.guard_found as a stop code on the cpu loop.
There is no reason to be using both. All instances of bx_guard.interrupt_requested can be replaced with guard_found.guard_found and the sim will run perfectly. All you need to do is change your mind about the function of guard_found.guard_found.

Most debuggers will only display one CPU at a time. So you only need to break one at a time.

Also, a breakpoint in the simulated code will only break one CPU at a time. There is no reason for the others to stop.

Also, if a breakpoint breaks one CPU, and ALL of them stop -- then how do you (the user) know which one hit the breakpoint? It is very clear if only one CPU stops.

stlw wrote: OK, I have simple proof for you. Add the line BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C somewheere in thee middle of the cpu_loop and hope it will break into debugger every instruction. It will not.

	// convenient point to see if user typed Ctrl-C
	if (bx_guard.interrupt_requested && (bx_guard.guard_for & BX_DBG_GUARD_CTRL_C))  {
		BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
		return(1); // Ctrl-C pressed
	}	// convenient point to see if user typed Ctrl-C

	if (BX_CPU_THIS_PTR guard_found.guard_found == BX_DBG_GUARD_CTRL_C)  {
		return(1); // Ctrl-C pressed
	}

To supply you which CPU hit the watchpoint is trivial. Also trivial to make the watchpoints .

It is your compiler that is not windows-compliant.
The system .h file that contains these controls is called commctrl.h

Some of these controls DO have minimum OS requirements. If you look in that non-standard .h file of yours, you will see that all of the constants that are missing in the compilation are IN the file, but have #ifdefs around them. The reason they are not compiling is that you are not providing the right #defines for the #ifdefs from your compiler's command line. Find out what #defines you need, and then the compilation will work better -- except that there are two small bugs in the code you have, and the #pragmas that WindowsNT wrote seem to be slightly non-standard. I have better code with no pragmas and no bugs, and will send it to your osdev mailbox today, I think.

I am not concerned about watchpoints. I am concerned about mode breaks. Please tell me how I am supposed to do the following:

The user has CPU(x)->mode_break set on two CPUs, of an 8 CPU system. One of the CPUs sees a mode change. It sets bx_guard.interrupt_requested. The whole simulation stops. Now: how do I show the user what caused the simulation to stop? How do I know it was a mode change? How do I know which CPU it was? You are leaving me no way to find out.

There are several other error conditions that set bx_guard.interrupt_requested, without telling me which CPU caused the error. This is also worthless.

bewing wrote:There are no non-standard controls used. Every control that is used is on this msdn list.

It is your compiler that is not windows-compliant.
The system .h file that contains these controls is called commctrl.h

Some of these controls DO have minimum OS requirements. If you look in that non-standard .h file of yours, you will see that all of the constants that are missing in the compilation are IN the file, but have #ifdefs around them. The reason they are not compiling is that you are not providing the right #defines for the #ifdefs from your compiler's command line. Find out what #defines you need, and then the compilation will work better -- except that there are two small bugs in the code you have, and the #pragmas that WindowsNT wrote seem to be slightly non-standard. I have better code with no pragmas and no bugs, and will send it to your osdev mailbox today, I think.

val = BX_CPU(CurrentCPU)->xmm[i]..xmm64u(1);	// get the value of "xmm(i)_hi" register
val = BX_CPU(CurrentCPU)->xmm[i]..xmm64u(0);	// "xmm(i)_lo"

bewing wrote:Yes, I knew about the error in FillSSE. It is fixed in the new version.

Your menus are missing, clearly.
All the functions you cannot see are in the menus. They are also available as hotkeys, of course.

So now we just need to figure out why your compilation did not include the enh_dbg2.rc file. If the patch worked, then it should have been included from the win32res.rc file. Is your enh_dbg2.rc file in the main bochs directory? If you cat win32res.rc, do you see the #include "enh_dbg2.rc" at the end?

Filling the memory dump window is done from the menu (or hotkey). Showing other regiisters is done from the menu. Internal debugger prompts are displayed/hidden by a selection in the menu. The meaning of Step N? It is the same as in: bx_dbg_stepN_command. Proceed? It is the internal debugger "p" command, but I am getting rid of it.

7. Resizing is very hard. I don't feel like writing 300 lines of code to do it.

8 & 9. I will look at them again, and see if they work.

And in the version I will send you shortly, the threading is commented out, except for the fact that I am bypassing the internal debugger.

The issue about stop reasons has nothing to do with the internal debugger. I am not using the internal debugger for anything anymore.

OK, I fixed the error in FillPAGE.
There is no error in FillAsm, because i=BufLen is always 0 the first time through the loop, and p is initialized immediately. I changed it a little anyway, to prevent the warning.

The minimum OS requirement is Win98 -- there is no way to go to Win95 and have any of it run, at all.

In this version, the program cannot be turned into a .cpp file, because that would mean modifying the Makefile, which cannot be done with a patch.