 |
 |
 |
 |
|
|
|
||||
Total/db User's Guide |
|||||
Total/db Overview
Total/db is a robust and powerful debugger tool chain that supports debugging of various LynxOS targets. Its modularity allows a variety of configurations suitable for the needs of particular applications.
Included Components
Total/db consists of the following component programs. Each program runs as a separate process:
GDB
GDB is the GNU debugger and is the "core" of Total/db. LynuxWorks has improved and enhanced GDB in a variety of ways for better debugging LynxOS targets. Readers are advised to read "Debugging with GDB" to get general familiarity with GDB and then the following chapter "LynxOS GDB Enhancements" for the LynuxWorks GDB-specific issues.
GDBServer
GDBServer is a part of the GDB package. GDBServer serves as the remote debug target agent for remote user process debugging. For its details, refer to "LynxOS GDB Enhancements".
Insight
Insight is the graphical user interface (GUI) front-end for GDB. It runs under the X-Window system and provides GDB with an intuitive GUI particularly good at displaying complex data.
Insight provides only the user interface using GDB as the "debug engine." It knows very little about the debug target, is independent from the debug targets, and is usable with a variety of different debug targets, including LynxOS applications.
SSPP
SSPP is a simple proxy server program that extends the physical reach of serial line remote debugging using GDB. Refer to "LynxOS GDB Enhancements".
SKDB
SKDB is a simple machine-level symbolic kernel debugger. SKDB provides interactive access to the LynxOS kernel internals including device drivers. It works as the debug agent for remote kernel debugging with GDB. Refer to "Simple Kernel Debugger - SKDB".
User Process Debugging vs. Kernel/Device Driver Debugging
LynxOS distinguishes CPU execution modes between user and supervisor. A user process runs in user mode with limited privileges. Supervisor mode controls all kernel activities including system calls, devices drivers, interrupt handling, and so forth.
Due to the differences in exception handling and other operations between the two modes, appropriate consideration must be given before selecting a debugging tool. Table: User Process Debugging vs. Kernel/Device Driver Debugging lists the options available for each CPU execution mode.
w/ GUI
Local Debugging versus Remote Debugging
LynxOS can be configured from an embedded system to a full-featured workstation with different levels of available resources including the user interface and file systems. If the target system has enough resources, it is possible to set up the debugger on the same machine; this is called local debugging. If the target is poor in resources or if a more powerful or different host workstation is preferred, perform remote debugging over a communication channel.
Local Debugging
User Process Debugging
GDB can run locally on the target machine for full source level debugging. Insight can also run on the same machine to provide GUI.
Kernel/Device Driver Debugging
SKDB provides stand-alone machine level local debugging on a serial terminal port or a video console. There is no source level or GUI kernel debugging (see Table: Local Debugging).
Remote Debugging
Remote debugging uses two machines, one running the LynxOS target application is called the debug target, the other running the debugger is called the debug host. The debugger program on the debug host communicates with the remote debug agent program on the debug target using a remote debug protocol through the communication channel. The debug agent, the remote debug protocol, and the communication channel differ between user process debugging and kernel/device driver debugging.
Symbol Files
In remote debugging, both the debug host and the debug target must have the same compiled binary image files. The debug host uses the files for obtaining symbols and other debug information while the debug target uses the files for actual program execution. The debug target's files may be stripped of symbols in order to reduce their size, but they must be synchronized with the host's files; otherwise, the debugger may behave incorrectly or unexpectedly.
User Process Debugging
There are two choices for the communication channel:
- TCP/IP provides reliable and fast communication, but it may not be available on simple embedded targets
- A serial line such as the RS-232 may be available on most targets for remote debugging but it is usually slower and less reliable than TCP/IP communication. A serial line also limits the distance between the host and target (see SSPP below).
With either communication channel, GDBServer must run on the target as the remote debug agent. GDBServer is a much smaller program (~100KB) than GDB and it translates the remote debug protocol into debug system calls and vise versa. Once a remote debug communication is established, there is no difference between serial line debugging and TCP/IP debugging.
One can optionally run Insight as a GUI (graphical user interface). Insight can run on the same host as the GDBs, or yet another host machine, in which case Insight communicates with GDB though a TCP/IP channel. Because Insight uses the X-Window, the display server (user interface) can be run on another machine.
Kernel/Device Driver Debugging
With Total/db, remote debugging is the only way to perform source level debugging optionally with GUI. The debug target is connected through a serial communication line such as the RS-232 to the debug host. There are no Ethernet or other types of communications available for remote kernel debugging (except SSPP). Like remote user process debugging, one can optionally use Insight for an intuitive GUI. SKDB works as the remote debug agent on the target.
Using sspp to Extend Serial Line Remote Debugging
In either remote user process or remote kernel/device driver debugging, if the remote debug target machine has only a serial port for communication with the debug host, this usually limits the physical distance between the two machines. LynuxWorks provides a solution to this: a third computer called a proxy server running a server program sspp between the debug target and debug host will convert the serial line connection to TCP/IP communication so that the host machine can be located anywhere as long as there's a TCP/IP communication channel between the debug host and the proxy server.
Cross Debugging
In remote debugging, the debug host does not necessarily have to have the same CPU architecture and/or run the same operating system as the debug target. If the debug host has a different CPU architecture and/or runs a different operating system from the target, it is called cross debugging, whereas debugging with the same CPU architecture and operating system is called native debugging. Choose the cross debug host from the combinations of debug targets and hosts LynxOS supports.
Total/db Configuration Options
Total/db allows a wide rage of flexibility in configuration, from stand-alone character based debugging to fully networked GUI based debugging. The following diagrams represent typical Total/db configurations.
Kernel Debugging Configurations
User Process Debugging Configurations
Supported Languages
Total/db currently supports the C and C++ programming languages plus the target's assembly language only.
Source Code
Parts of Total/db, namely GDB and Insight, are derived from public domain software. Though it is possible to obtain and build the source code for these programs, it may not work properly. Any such build is not supported by LynuxWorks.
|
LynuxWorks, Inc. 855 Branham Lane East San Jose, CA 95138 http://www.lynuxworks.com 1.800.255.5969 |
| |
|
|
|