Table of Contents
Kgdb is organized into three basic components:
kgdb core
The kgdb core is found in kernel/kgdb.c. It contains:
All the logic to implement the gdb serial protocol
A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.
The API to talk to the kgdb I/O drivers
The API to make calls to the arch specific kgdb implementation
The logic to perform safe memory reads and writes to memory while using the debugger
A full implementation for software breakpoints unless overridden by the arch
kgdb arch specific implementation
This implementation is generally found in arch/*/kernel/kgdb.c. As an example, arch/x86/kernel/kgdb.c contains the specifics to implement HW breakpoint as well as the initialization to dynamically register and unregister for the trap handlers on this architecture. The arch specific portion implements:
contains an arch specific trap catcher which invokes kgdb_handle_exception() to start kgdb about doing its work
translation to and from gdb specific packet format to pt_regs
Registration and unregistration of architecture specific trap hooks
Any special exception handling and cleanup
NMI exception handling and cleanup
(optional)HW breakpoints
kgdb I/O driver
Each kgdb I/O driver has to provide an implemenation for the following:
configuration via builtin or module
dynamic configuration and kgdb hook registration calls
read and write character interface
A cleanup handler for unconfiguring from the kgdb core
(optional) Early debug methodology
Any given kgdb I/O driver has to operate very closely with the hardware and must do it in such a way that does not enable interrupts or change other parts of the system context without completely restoring them. The kgdb core will repeatedly "poll" a kgdb I/O driver for characters when it needs input. The I/O driver is expected to return immediately if there is no data available. Doing so allows for the future possibility to touch watch dog hardware in such a way as to have a target system not reset when these are enabled.
If you are intent on adding kgdb architecture specific support
for a new architecture, the architecture should define
HAVE_ARCH_KGDB
in the architecture specific
Kconfig file. This will enable kgdb for the architecture, and
at that point you must create an architecture specific kgdb
implementation.
There are a few flags which must be set on every architecture in their <asm/kgdb.h> file. These are:
NUMREGBYTES: The size in bytes of all of the registers, so that we can ensure they will all fit into a packet.
BUFMAX: The size in bytes of the buffer GDB will read into. This must be larger than NUMREGBYTES.
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call flush_cache_range or flush_icache_range. On some architectures, these functions may not be safe to call on SMP since we keep other CPUs in a holding pattern.
There are also the following functions for the common backend, found in kernel/kgdb.c, that must be supplied by the architecture-specific backend unless marked as (optional), in which case a default function maybe used if the architecture does not need to provide a specific implementation.