[Dwarf-Discuss] Callable interface for Fortran "coarray" features

Bishop, John E john.e.bishop@intel.com
Mon Dec 28 19:52:09 GMT 2020

I am no longer a committee member, but I am still involved with helping make Fortran debuggable.   I ask for comments on the possible extension described below.

Fortran now has an extensive set of features to support parallel program using a shared-memory paradigm.  This was introduced in the 2003 standard and enhanced in the 2008 standard and will be enhanced again in the future 2018 standard.

Different implementations of these features may use very different methods (e.g. MPI, shmem, real shared memory, home-brew message passing, RPC,..).  This means that the structures representing coarray concepts like coarrays, teams, events and barriers will not be the same in different Fortran implementations.  This makes them hard to describe in DWARF, as the features aren't generic.  In other words, even if we added DWARF primitive types for events and teams, the types would need to define per-producer access methods.

Further, coarrays are either cross-thread or cross-process or both; users in a debugger will want to reference memory which is resident in a different process, but the source code only has an integer "id" as the key.  The remote memory issue can be worked around if there is a debugger attached to each process and a debugger-supervisor which can talk to each of the per-process debuggers, and if the implementation is a simple one where the base address of the pseudo-shared memory is easily found.

It seems to me that one solution to the representation and debugging problems of representing coarrays in DWARF would be to define a callable interface.  Producers who wanted to be debuggable would implement the interface and add it to their run-time library.  Consumers which wanted to debug coarrays would check for those entry points and call them if they were present.   The interface routines would be generic, with opaque handle results for instances of types like event, team and barrier.  An example set is listed below.

This is a long way out of the usual DWARF paradigm.  I therefore request your opinion about whether this kind of thing could become part of DWARF or possibly just a "you might like to try this" appendix.


Example queries
1.            how many images are there (overall and by team)?
2.            what image is this (currently, originally and by team)?
3.            what team is this (team number, opaque result)?
4.            what images are in the specified team (in-team, original ids)?
5.            what is the parent team of a team (opaque result or null)?
6.            what is the state of this image (waiting for response, in a barrier, computing,..)?
7.            is this address in a coarray and if so, which (base-address of coarray, opaque result)?
8.            what is the value of this offset in this specified coarray in this specified image?
9.            what is the value of this address in this specified image?
10.          if possible, set the value of this type at this offset in this specified coarray in this specified image, tell me if it worked.
11.          if this image is in a barrier, with which images is it synching?
12.          if possible, switch context to specified image (in team, original)
13.          what is the event for this address (opaque result)
14.          what is the value of the specified event?
15.          if possible, set the specified event to this value
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20201228/a6bb8fee/attachment.html>

More information about the Dwarf-discuss mailing list