LCP GDB

LCPGDB: A Debugger for the Lanai

lcpgdb is a slightly modified version of GDB-4.16 designed to allow debugging of both contexts of the Lanai control process at the same time. It currently runs on Sparc workstations with Solaris 2.5. It will not build for other platforms yet, as it lacks configuration information.

Click here to download a copy of lcpgdb 1.0 (5.6MB).

Patch for lcpgdb 1.0 to work with Myricom's driver (run patch in the lcpgdb/gdb directory).

General Information

Without access to the alternate context, a Lanai processor context can only be stopped by throwing it into an infinite loop. An inserted jump to such a loop has a shadow instruction, preventing atomic insertion of breakpoints.

To ensure some reasonable level of safety, lcpgdb provides two context breakpoint routines (lanai_user_breakpoint and lanai_system_breakpoint) that require a change of only one instruction to enter the breakpoint loop, and can therefore be broken atomically. So long as a context calls the appropriate context breakpoint handler periodically, lcpgdb enables the user to stop the context with CTRL-C (SIGINT). The context breakpoint handlers avoid the use of the standard function prologue and epilogue to make them reasonably fast (4 instructions + the usual 3 instruction calling sequence).

In order to use all of the features of lcpgdb, an LCP must include the file lcp_break.c as one of its sources and must have been compiled with the symbol "DEBUG" defined. Prototypes for the context breakpoint handlers are defined in lcp_break.h. Without such library support, lcpgdb has access only to symbolic information, precluding any sort of execution control and allowing only the following features:

  1. evaluation of context-free expressions consisting of static variables, specific memory locations, and all static symbols
  2. assignment of expressions to static variables or memory locations
  3. regular expression searches of the symbol tables
When the LCP has been compiled with library support, lcpgdb also allows control of a single context's execution. The additional features include the following:

  1. use of CTRL-C to stop a running context
  2. breakpoints, optionally with conditions and skip counts
  3. stack backtraces
  4. selection of and expression evaluation within any stack frame in the current backtrace
  5. register evaluation (and assignment for most of the registers in a context)
  6. single-stepping (machine level or source level, into or through calls)
To use lcpgdb, point it to the executable file for the LCP currently running on the Lanai, then use the attach command to attach either to the entire LCP (without library support) or to a particular context (user or system). Attaching to a context automatically attempts to stop that context, as if the user had hit CTRL-C, and prints a stack backtrace once the context stops. lcpgdb has no notion of initiating or terminating an LCP.

With library support, a user can user the attach command to switch between contexts, with certain caveats. Setting breakpoints in code used by a running context can result in erroneous behavior, as the breakpoints are not inserted atomically. Before switching contexts with attach, the user should delete or disable any breakpoints in code used by the current context. Similarly, a user should never set a breakpoint in a routine used by both contexts.

While the user examines one context with lcpgdb, the alternate context is allowed to continue execution. To stop both contexts simultaneously, start a second lcpgdb and attach it to the other context. If an lcpgdb terminates gracefully, it first removes all breakpoints and allows both contexts to continue execution.

Notes

lcpgdb is designed for use with Myricom's lanai3-gcc compiler. It should be capable of understanding any code produced by that compiler, although a user might be surprised by the occasional absence of variables and the sometimes scrambled order of statement when optimization is used. The single-stepping capabilities of lcpgdb are limited, however, as a full Lanai emulator is necessary to determine the next "safe" breakpoint insertion location in the face of data hazards and the possibility of using the PC as the destination register for practically any instruction. If an LCP contains code generated by hand or generated by a compiler other than lanai3-gcc, lcpgdb might not be able to single-step through it. In such a case, lcpgdb attempts to notify the user.

Compiling an LCP that includes lcp_break.c without the DEBUG symbol defined is completely equivalent to compiling the LCP without inclusion of lcp_break.c and without any calls to the context breakpoint handlers. Such calls are silently removed unless the DEBUG symbol is defined, as is all breakpoint support code.

Certain operations commonly available in GDB are fairly difficult to support in the debugging model used by lcpgdb. Notably, lcpgdb does not allow the user to push or pop stack frames nor to set the values of the stack and frame pointers. Furthermore, lcpgdb prevents the user from changing the values of registers in the alternate context (although a simple attach command circumvents this limitation). Finally, lcpgdb offers no way to flush the cached register set, so that the values of alternate context registers (e.g., the APC) are most likely inaccurate.

Bug Reports

PLEASE DO *NOT* MAIL BUGS TO THE USUAL GDB BUG ADDRESS!

If you find a bug, please mail as detailed a description as you can to stevel@CS.Berkeley.EDU. I may or may not decide to fix it, but the chances are better if the bug occurred with code compiled by Myricom's lanai3-gcc.