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).
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:
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.
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.
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.