This is about a piece of the kernel, the <b>stub</b>, that connects to gdb to support debugging of the kernel. It is part of the kernel in that it runs in the same space, mode and authority as the kernel, but it is apart from the kernel in that the kernel is "its subject". It cannot debug itself.

The purpose of this note is to design before implementing, but also inform the user of the debugger how it works in order to undestand the debugging artifacts. The abstractions are very imperfect!

The design is for the Sparc but I hope it will be a portable design.

The stub talks to the UART which is connected by wire to a UART in a Unix box in which an instance of gdb runs with kernel symbols and also access to a keyboard and display where the person sits who is debugging.

gdb comes with a native ability to examine and control a program running at the other end of a communication link, especially UARTs. This is invoked by the gdb "target" command after gdb has read the symbol information.

The plan is to alternate between two states:
  the kernel to be running with traps arranged to invoke the stub,
  gdb or the user pondering the next step.
  
This means that gdb will be unable to interrupt the kernel but other means may be employed to knock the kernel in the head to make it trap.

The pre gdb kernel debugging starts with the kernel doing a "ta 0" instruction after it has been mapped but before it has begun to run. This shows up as a TRAP 0x80 in the ROM debugger. This provides an opportunity to set breakpoints and debug using the Open Boot function in the ROM. One speaks Forth and says "%npc set-pc go" to start the kernel running.

With gdb one includes the stub with the kernel and the same ta instruction is reported by gdb. Mutatis mutandis.

gdb conceives of just one address space, in our case that of the kernel. It is ignorant of user mode address spaces. The stub will speak to gdb solely of what is in the kernel map. It may be possibe to provide a mode where it looks into user space but I don't think so.

Artifacts:

Traps that are normal kernel events will be processed as usual after only a brief clance at the old psr value to see if it was a trap from the kernel. The only traps that should come from the kernel are the external interrupts.