cvs commit: src/sys/i386/i386 trap.c src/sys/amd64/amd64 trap.c

[Stephan Uphoff]

On Wed, 2005-06-29 at 11:42, Marcel Moolenaar wrote:
> On Jun 29, 2005, at 6:47 AM, Stephan Uphoff wrote:
> 
> > this is just a quick fix to get basic debugging capabilities back for
> > some common environments. I plan to migrate parts or all of kdb_trap
> > back to MD code to deal with SMP race conditions.
> 
> That is not a good idea. The overall behaviour of entering the
> debugger in inherently MI. The MD specifics are in the details,
> which require nothing more than some MD callback functions to
> fill in the blanks or create the right abstraction.
> Race conditions are not MD phenomena either, but may require MD
> techniques to prevent them. Hence, to fix race conditions you
> don't have to degenerate MI code to MD code, provided you have
> proper MD callback functions to fill in the blanks or create
> the right abstractions.

Don't panic !
The last thing I want to do is to totally dismantle the current kdb_trap
or sprinkle MI code all over the different architecture directories.
The console stuff definitely belongs in the MI part.
However for readability I would rather have:

kdb_trap_md() {
	md code;
	....
	if (really_enter_debugger)
		kdb_trap_mi();
	....
	md code;
}

instead of:

kdb_trap_mi() {
	really_enter_debugger = md_debugger_enter_code();
	if (!really_enter_debugger)
		return

	.. stuff ..

	md_debugger_exit_code();
}

I am all for MI code and callback functions.
However kdb_trap is only called from MD code.
Guaranteeing a certain execution environment for the MI code is all I
care about. There is no abstraction gained by using MI callbacks on
entering/exiting the MD kdb trap function.
This being said I am not religious about it and can use callbacks if you
feel strongly about this. I just think callbacks would be a bit silly in
this context.

Stephan