Up: GDB Agent for RTEMS
This gdb stub is an implementation of the remote end of the
GDB remote protocol for a RTEMS target. Unlike other stubs
available for RTEMS (e.g., the m68k implementation), this
version does NOT run at `exception' level but is intended to
be less intrusive. It's primary use is debugging of user-level
/ application code rather than the kernel itself (kernel
debugging is still possible to a certain extent but the stub
essentially needs a functional and initialized system to
The stub runs as a `daemon task' executing debugging commands
as demanded by the host gdb. Unlike a `low-level stub' which
interrupts/stops the target system as a whole while talking
to gdb, this implementation only affects the execution of
one or multiple `target threads' leaving other tasks alone.
As a consequence, it is possible to use TCP/IP as a communication
protocol (no breakpoints in networking must be set, though!).
Gdb semantics expect the target system to be `interrupted' or
`stopped' while listening to gdb commands. This implementation,
OTOH, attempts to be as little intrusive as possible. For this
purpose, a list of `stopped' tasks is maintained internally.
Tasks are interrupted only as a result of hitting a breakpoint,
incurring an exception or an explicit request by the debugger.
Interrupted tasks can be inspected as usual (stack frame,
register contents etc.) and can be `continued/resumed'.
Only `interrupted' tasks can be inspected - the others continue
The stub also creates a special helper task context which is
always interrupted, hence it is possible to do non-task related
work (inspect/change memory, disassemble, ...) without having
to stop an application task.
A patch to `gdb' is provided extending the remote protocol
in order to support loadable modules. Gdb can inquire the
list of currently loaded modules and their section addresses
as well as load/unload additional modules on the fly.
While many parts of the stub are intended to be portable
and target-architecture independent, there are a few pieces of code
which are BSP/CPU dependent. Currently, low-level support
has been implemented for the i386/pc386, m68k/coldfire and
powerpc/shared (and derived - should probably work on any
`new-exception processing' ppc BSP) BSPs.
Adding support for a new target should not be extremely
hard. It mainly consists of writing two routines for
packing/unpacking register values into a gdb-formatted
array. Also, a low-level exception handler needs to be
written (mostly for mapping exception codes to signal numbers).
E.g., the i386/pc386 specific file consists of 400 lines
of quite straightforward code.
One of the strengths of the gdb remote protocol is its simplicity
which makes it possible to use many character-stream based
I/O methods for exchanging messages.
Currently, the stub supports TCP/IP and serial port communication
via RTEMS' termios driver.
One important design goal was not having to patch gdb itself.
Unfortunately, it was not completely possible to meet this
goal. However, the necessary patches are believed to be
as small and as modular as possible.
- A small patch is needed to fix a bug [has been submitted
as GDB bug #2029
but to-date, I don't know if it has been merged] in the
powerpc stack unwinding.
- A small patch is needed to make it possible to obtain
the list of tasks running on the target without interrupting
and stopping them all
(which would result in violating design goal #1: only
interrupt tasks on request [explicit or breakpoint]).
- Additional patch adds a new gdb target (``rtems-remote'')
extentions to support loadable modules (CEXP). Note that
the stub works fine without CEXP, however.
Up: GDB Agent for RTEMS