1. Reference Implementation of the High Performance Debugging (HPD) Standard Kevin London ( london@cs.utk.edu ) Shirley Browne ( browne@cs.utk.edu ) Robert Hood ( rhood@nas.nasa.gov ) Phil Mucci ( mucci@cs.utk.edu ) John Thurman ( thurman@cs.utk.edu )

2. Work partially funded by the DoD High Performance Computing Modernization Program, ARL, CEWES, and NAVO Major Shared Resource Centers, through Programming Environment and Training (PET). Views, opinions, and/or findings contained in this report are those of the author(s) and should not be construed as an official Department of Defense position, policy or decision unless so designated by other official documentation.

3. What is HPD? • HPD is an implementation following the standard proposed by The High Performance Debugger Forum. • A debugger for parallel and multi-threaded applications. • Is light weight, easy to use and presents multiprocess/multithread information in a format that is easy to understand.

4. What is the High Performance Debugger Forum? • The Forum is sponsored by The Ptools Consortium • The goals are to define a useful and appropriate set of standards relevant to debugging tools for HPC systems and to accommodate needs of both users and tool developers. • http://www.ptools.org/hpdf/

5. The High Performance Debugger Standard • The standard was written to address the following types of programs: • “high performance” in nature (i.e., performance is an important consideration) and typically parallel • written in one or more high-level languages • intended to run on possibly many different computer systems • The standard assumes explicit parallelism as the basic programming model. • The standard is applicable to both shared-memory programming (multiple threads of execution in an address space) and distributed-memory programming (multiple processes co-operating via message-passing libraries, such as PVM or MPI)

6. The High Performance Debugger Standard • The standard distinguishes the functionality needed for threads-only, process-only and multilevel (multi-process and multi-thread) models of parallelism • The overall objective of the standard is to make it possible for debuggers of all three types to provide support that is consistent as possible, given the constraints imposed by the underlying model. • The major languages considered were Fortran (F77 and F90), C, and C++.

7. p2d2/HPD’s Client-server Architecture remote server a.out user interface distribution manager debugger server remote server a.out client remote server a.out

8. The Command Line Debugger • The command line debugger will be written so that it aggregates data when it returns, so that the results will be easier to read. • The command line debugger will adhere to the standard so that multi-process applications will be easily controlled. • It will be a good alternative to a GUI for those who have poor network connections.

9. The GUI (e.g. p2d2) The GUI will be a module that will easily be replaceable so front-ends can be changed reasily. Currently P2D2 will be the GUI front end. Also the Data Management Layer, Debugger Server, and DBX/GDB clients will be coming from P2D2. These will be changed to support the command line debugger. The GUI will also be able to have a command line debugger within its display.

10. The Data Management Layer • This layer contains all of the process information including execution names, processor name the executable is running on, and more information that the debugger might need. • This is the layer that keep track of groups of processes. The DM layer has the ability to iterate over these groups sending the commands to the Debugger Server level.

11. The Debugger Server • The Debugger server ‘s main duty is to communicate with the debuggers on the various machines/processors. • The debugger server sends the commands through the DBX/GDB Client so that we can have abstract commands and the Client translates the commands to the native GDB or DBX commands. This allows support of other debuggers rather easily.

12. GDB/DBX Client • In addition to mapping the abstract commands to the native GDB/DBX commands, the Client is also responsible for parsing the output that comes from the debuggers on the various machines/processes, thus allowing the command line debugger and the GUI to get back the same format of information no matter what debugger the machine/processes are using.

13. What will the beta release contain (est. Feb 99)? • A subset version of the command line debugger implementing the following: • run, continue, break, print, where • Due to memory issues run will only work the first time you use it, then you must exit out and restart the debugger. • GDB will be the only per-process debugger supported initially.

14. Limitations of the Beta Release For simplicity the initial release will implement a subset of the functionality and commands specified by the standard. • No memory management so you must restart the debugger each time you want to run your application. • Some commands will have limited functionality to make the initial release easier to finish. • DBX will not be supported in the Beta Release • No conditional breakpoints will be supported in the Beta Release.

15. Future Work • DBX as the per-process debugger in addition to GDB • Add functionality to implement as much of the standard as possible • Memory clean-up routines • Make the code more modular

16. For More Information • http://icl.cs.utk.edu/projects/hpd/ • http://www.ptools.org/ • http://www.ptools.org/hpdf/ • http://www.ptools.org/hpdf/draft/