Notes 2020 03 26

Meetings Notes 2020-03-26

Participants

• Martin Schulz
• Joachim Protze
• Chris Chambreau
• Marc-Andre Hermanns

Topics

• Why do we need the void *

  • DEbugger needs to identify which process the information is about
  • void * is an opaque handle to identify a process by the Debugger (external process)
  • Debugger & Library agree in a handshake on how to identify a process
    • void * owned by the Debugging Library (outside of the MPI process)
  • Using the same callback function interface (just use the void * for something else)
    • Language-specific binding could be defined for a Debugger (adding specific additional arguments)
    • LID has semantics, and there needs to be some mechanics to generate those additional arguments

• We need to focus on:

  • Which functionality do we already have?
  • Which functionality do we need in addition to that?
    • Envelope and Size/Extend calls should be available for third-party interface

• Which handles do we want to include?

  • Communicators
  • Datatypes
  • Windows
  • Operators

• Some interface to introspect base types (MPI_COMM_WORLD, MPI_INT, MPI_SUM) needed.

• We should contact Debugger People

  • Tony Tie (suggested to move most of the OMPD library to DWARF)
    • Allow OPMD queries be done via DWARF

• How does the Debugger know what a handle actually is

  • 1. Approach: Binary compatibility of the debugging interface
       • If the interface ist not a binary compatible interface the debugger needs to implement an adapter for each MPI library the debugger wants to support

• Ask library: How big ist your handle type and pass a variable of that size to library.

  • Pass in a communication handle
  • Return a debugging communication handle
    • With storage where the debugger can attach additional informati

• Predefined: yes/no?

  • if yes: hand back the answer for that specific object (could be an enum with a fixed value or a string)
    • We need to translate the MPI handles into MPI debugging handles
      • Debugging handles are a fixed type but owned by the debugging library
        • Often stores the address of the object in the runtime process
          • INT-based handles could look up the info once and cache the handle info in the debugging handle
        • Should also contain info about which process the object belongs to

• ompd_get_thread_handle might be a good blueprint for getting information debugging handles

  • We need an ABI

• @Joachim to sketch a quick presentation of the key ideas?

• Let's reach out to TotalView and ARM to get ideas