...
Debugging code on an embedded system is a difficult problem. The basic features of embedded environments – isolation, limited code space – usually preclude having a fully implemented shell with the entire development tool chain present on the dedicated processor. Many commercial vendors (VxWorks, Xilinx) include remote debuggers usable over various connection protocols, but for RTEMS, there wasn't a good way to run debuggers on a large cluster of embedded processors. In this document we discuss the two debugging options we have available for dealing with RCEs: XMD and The GDB stub.
Xilinx Microprocessor Debugger (xmd)
| Anchor | ||||
|---|---|---|---|---|
|
XMD (Xilinx Microprocessor Debugger) is a low-level (assembly language) debugger that is provided by Xilinx as part of a product called the Embedded Development Kit (EDK). It communicates with the PowerPC System-On-Chip over a JTAG interface via a host computer's USB system. The secret of a large portion of this magic is that it is able to inject instructions into the processor over JTAG (interestingly, these instructions can be recorded to text files and disassembled with some effort). XMD and the EDK is installed on SLAC AFS.
...
| Wiki Markup |
|---|
This will connect to the primary USB cable. There is an option to use a different USB cable: {{-cable type xilinx_platformusb port usb2\[\#\]}} where {{\#}} is the USB2 port number you wish to use. |
GDB over XMD
| Anchor | ||||
|---|---|---|---|---|
|
We may use GDB to connect to XMD through network socket 1234, giving us a full source-code debugger. This does have limitations in that GDB connected in this way cannot see the full RTEMS task (thread) list.
...
If one wishes a more complete debugger, with full RTEMS thread and task support, we can connect GDB to the RCE over TCP/IP, as described below.
...
RTEMS GDB stub
| Anchor | ||||
|---|---|---|---|---|
|
Till Straumann of SSRL wrote a nice GDB stub to enable remote debugging of an RTEMS system over a local network. This code has been ported to the RCE system and methods have been developed to use it in conjunction with the RCE dynamic linker developed by Steve Tether.
Requirements
The implementation developed at SSRL requires some patches to GDB in order to run. This patched version of GDB is available via the CTK group's AFS space in /afs/slac/g/cci/package/gnu. Also, the core code on the RCE must have the GDB stub compiled in and started automatically. This is true as of core 1.3 (commit 1135). Note: the GDB daemons only run on the development core, not in the production core.
Starting out
The GDB process needs to be run from a machine with unrestricted access to the RCE rack. This means that one must run from a machine on the 172.21.6.XXX network, such as rdcds104, or an atca equivalent. This requirement is expected to change with the rationalization of the networking in Lab 1.
...
We can now use breakpoints that are defined in the core development code (such as inside the telnet protocol, or in one of the shell commands.) If we have a task available, we can run it from the shell using runTask. However, as the symbols in this task aren't in memory yet, we cannot yet set a breakpoint inside that task.
Breakpoints in dynamically linked libraries
To set breakpoints in these libraries, we need a bootstrap procedure. Here is one example of a GDB macro which will bootstrap the breakpoint:
...