Reference Implementation of the High Performance Debugging HPD Standard

1
Reference Implementation of the High Performance
Debugging (HPD) Standard

• Kevin London ( london_at_cs.utk.edu )
• Shirley Browne ( browne_at_cs.utk.edu )
• Robert Hood ( rhood_at_nas.nasa.gov )
• Phil Mucci ( mucci_at_cs.utk.edu )
• John Thurman ( thurman_at_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/HPDs 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/