Chapter 6. KGDB Internals

Table of Contents

Architecture Specifics
kgdboc internals
kgdb8250 API

Architecture Specifics

kgdb_skipexception — (optional) exit kgdb_handle_exception early
kgdb_post_primary_code — (optional) Save error vector/code numbers.
kgdb_disable_hw_debug — (optional) Disable hardware debugging hook
kgdb_breakpoint — compiled in breakpoint
kgdb_arch_init — Perform any architecture specific initalization.
kgdb_arch_exit — Perform any architecture specific uninitalization.
pt_regs_to_gdb_regs — Convert ptrace regs to GDB regs
sleeping_thread_to_gdb_regs — Convert ptrace regs to GDB regs
gdb_regs_to_pt_regs — Convert GDB regs to ptrace regs.
kgdb_arch_handle_exception — Handle architecture specific GDB packets.
kgdb_roundup_cpus — Get other CPUs into a holding pattern
struct kgdb_arch — Describe architecture specific values.
struct kgdb_io — Describe the interface for an I/O driver to talk with KGDB.

Kgdb is organized into three basic components:

  1. 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

  2. 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

  3. 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.