next up previous contents index
Next: 10.17.3 Debugging address spaces Up: 10.17 Remote Kernel Debugging Previous: 10.17.1 Organization of remote

10.17.2 Using the remote debugging code

 

If you are using the base environment's default trap handler, then activating the kernel debugger is extremely easy: it is simply necessary to call an appropriate initialization routine near the beginning of your kernel code; all subsequent traps that occur will be dispatched to the remote debugger. For example, on a PC, to activate serial-line debugging over COM1 using default serial parameters, simply make the call `gdb_pc_com_init(1, 0)'. Some example kernels are provided with the OSKit that demonstrate how to initialize and use the remote debugging facilities; see Section 1.6.1 for more information.

If you want a trap to occur immediately after initialization of the debugging mechanism, to transfer control to the remote debugger from the start and give you the opportunity to set breakpoints and such, simply invoke the gdb_breakpoint macro immediately after the call to initialize the remote debugger (see Section 10.17.11).

If your kernel uses its own trap entrypoint mechanisms or its own serial line communication code (e.g., ``real'' interrupt-driven serial device drivers instead of the simple polling code used by default by the toolkit), then you will have to write a small amount of ``glue'' code to interface the generic remote debugging support code in the toolkit with your specific OS mechanisms. However, this glue code should generally be extremely small and simple, and you can use the default implementations in the OSKit as templates to work from or use as examples.



University of Utah Flux Research Group