to signal that the build is happening on a machine with an ELF
toolchain. This is temporary, until a better toolchain-recognition
scheme is worked out.
(1) bsd.prog.mk already includes bsd.subdir.mk, and
(2) including bsd.subdir.mk first screws up the clean/cleandir targets
in such a way that the program's objects don't get blown away
when you make clean.
- Only pass user trace traps and breakpoints on to trap().
Gets rid of some hair in the trace/breakpoint trap cases.
- Before entering the debugger, switch to a temporary
stack so that the debugger can alter the stack pointer.
- Add glue for KGDB (still not complete).
Some other minor cleanup:
- Protect against some bad pointer derefs.
- Be more a little more verbose when a fatal trap
occurs to aid debugging.
- Only pass user trace traps and breakpoints on to trap().
- Before entering the debugger, switch to a temporary
stack so that the debugger can alter the stack pointer.
- Add glue for KGDB (still not complete).
Clearly mark the MMU enable trampoline code.
the keyboard to work. Fixes a bug where booting with `-d' worked
only on systems using a serial console.
While I'm here, eliminate some redundancy in the ite console intialization
code.
This fixes a critical bug where a clock interrupt would happen sometime
between the call to hp300_calibrate_delay() and when proc0 is initialized.
This ends up dereferencing a bad pointer in itimerdecr(), which scribbles
over the first page of kernel text, specifically vectors 46 and 47 (decimal).
To complicate matters, the way the bug manifested itself was different
depending on whether or not DDB was configured into the kernel. When
DDB is in the kernel, kernel text is mapped read/write. When DDB is not
in the kernel, kernel text is mapped read-only. Note that the kernel
scribble happens early, typically before the console is initialized.
In the non-DDB case, the kernel will hang as soon as it's loaded because
the access causes a fault (before the console is initialized, so you
don't see the trap).
In the DDB case, the access does _not_ cause a fault. However, the
mechanism used to enter the kernel debugger is to issue a "trap #15".
Conveniently, this is one of the corrupted vectors (47), thus rendering
DDB useless (it actually caused a recursive panic/trap loop).
This _WILL_ be in the first 1.2 official patch.
cgd