Formation of the High Performance Debugging Forum

Introduction

A Birds-of-a-Feather session was held at Supercomputing '96 to explore community interest in a debugging standards effort. It was decided at that session to go ahead with this effort and to hold the first formal meeting of the High Performance Debugging Forum in March, in conjunction with the SIAM Conference on Parallel Processing for Scientific Computing. An initial steering committee for the Forum was created, consisting of Jeff Brown, Joan Francioni, and Cherri Pancake.

General Discussion

The debugging community has yet to come up with one debugger that meets all of these goals. This is not because the goals aren't understood. Rather, it is is because debugging tools are very complex pieces of code that must be compatible with a specific machine with a specific compiler and under a specific operating system. As these three components are constantly changing in the high performance computing arena, it has been difficult for researchers and vendors to have access to stable platforms long enough to be able to develop appropriate tools. Further, there are no accepted standards about what debuggers should do nor about what kinds of support compilers/operating systems should provide to the debugging program.

This lack of standardization affects both users and developers of parallel debuggers. Users find they must learn a new tool for every machine where their applications execute. The problems they experience range from non-standard and inconsistent command semantics (e.g., breakpoint and next) to confusing screens full of too many windows and an inability to do the things they need done. The effort required to learn a new tool also frequently turns out to be a major issue. It is not cost-effective for a user to spend a large amount of time learning a new tool for a platform that may not be in existence for very long, or for a tool that is not very useful.

For debugger implementors, the difficulty of writing a debugger as new systems are introduced is greatly increased by the lack of established standards. They find that they are forever re-developing the same functional code as machines, compilers, and operating systems change under their feet. Tool developers are frequently behind the power curve when it comes to actual tool deployment. New and complex computing platforms and programming models require sophisticated development tools in order to exploit their full power, yet development tools are invariably the last software to arrive on a new system. The tools stabilize just in time for the next generation of system to be introduced. This cycle needs to be broken.

Finally, both users and developers cite the lack of user experimentation and user input during the development process as a serious impediment to building useful debugging tools.

High Performance Debugging Forum

In general, HPDF's efforts will focus on parallel systems and languages that are being used for research and production in the HPC arena. In particular, the scope of effort will be constrained as follows:

1. The standards developed will not preclude the use of any particular parallel programming model. Every debugging command does not have to be applicable to every programming model, but no command should be in conflict with any model.
2. The standards developed will not preclude the use of any particular parallel architecture.
3. The standards will be developed to work with structured programming languages. Functional and interpreted languages will not be explicitly considered. The emphasis will be on languages commonly used in scientific programming, such as F77, F90 and C. (HPF??, C++??)
4. Standards efforts will address both user level standards and standards for the underlying software infrastructure, such as a common API to compiler-generated information about a program.
5. Different standards will be addressed in an orderly sequence. In order to expedite their adoption and implementation, HPDF will capitalize where possible on converging technologies, de facto norms, or other instances of "low-hanging fruit."
6. Where possible, standards will be defined in a series of levels, such that each successive level builds upon the earlier ones.

Initial Focus of Effort

First Meeting

There will be no registration fee for persons who pre-register for the first meeting, which will be sponsored by the Northwest Alliance for Computational Science and Engineering. A registration form is attached to the end of this document. Late and on-site registrants will be charged a $75 registration fee to help defray last-minute expenses.

The objectives of the first meeting are:

• define what debugging features will be included in Level 1 and how to partition the work
• determine how much/little consensus already occurs among parallel debuggers in terms of Level 1 features
• lay out a plan to accomplish a Level 1 specification by SC'97
• determine milestones and specific goals
• establish initial working groups

Initial Effort for Command-Line Interface Levels

For that reason, we are suggesting that initial efforts be directed at debugger control features. There is considerable overlap in this type of functionality from one existing debugger to another, and that functionality is well understood. This appears to be an instance of "low-hanging fruit."

It is important to note that, just because a feature is excluded from Level 1 doesn't mean it will be missing from a debugger that conforms to the standard. The original operations will still be there -- they just won't be standard yet; only the Level 1 features will be certain to be consistent.

[General note: The standards developed will be applicable to processes, threads, and sets of both.]

• Level 1: Command-Line Interface of Control Features
  • Execution Control: intermittent execution, including conditionals and watchpoints, stepped execution
  • Process/Thread Sets: defining sets, applying sets
  • Process/Thread/Processor States: examining state, modifying state
  • Program State: identifying code location, viewing source code
• Level 2: Command-Line Interface of Output Features
  • Data Display: displaying values of scalars and arrays, selecting portions of output (data filtering), targeted variables, targeted output values (A[i[j]] = 100), tabular and other display formats
  • Data Modification
  • Watchpoints and conditional watchpoints
• Level 3: Communication Features
• Level 4: Optimized/Assembly Code, Code Patching, other more advanced features?

Registration Form