Hi,

I wanted to write the following down, while it was fresh in my mind...

On today's MPI Handles concall (Jeff, Laust, Sven, Martin, and myself) I said that depending on typedefs (and types in general) in the debug interfaces was problematic. One usage model of the MPI Handles interface is that given an MPI object (e.g., a communicator), the debugger can use the introspection library to extract more information about that object. For example, the use can "hover" over a communicator variable in the program and the debugger will show more information (e.g., in a tool tip) about the communicator. As currently specified, the only way the debugger can automatically "deduce" that the variable is a handle on a communicator is to look at the variable's type. The current MPI Handles interface has a way for the debugger to discover the types for various MPI objects, but depending on the compiler implementation, MPI implementation, and application language (e.g., C, C++, Fortran), automatically deducing the object type may not be possible.

Here is the short list of problems we've encountered in the past with typedefs (and types in general):

1. typedef names have internal linkage, as opposed to class/struct/union definitions that have external linkage. That is, typedef names are not "visible" outside the compilation unit where they are defined. That makes them hard for the debugger to find, because they are not normally part of a symbol table indexing scheme, so the debugger often has to know where they typedef is defined in order to find its definition.
   
   We had this problem in the MPIR interface where MPIR_PROCDESC was a typedef to a structure containing the pid, host, and executable for a process. We had to play games (and still do) where we had to lookup the compilation unit containing the definition of the subroutine MPIR_Breakpoint (a subroutine with external linkage), and read the symbols in that compilation unit with the hope that MPIR_PROCDESC was defined in the same compilation unit. This happened on Darwin with Open MPI, and possibly elsewhere.
   
   My point is that whenever we can avoid typedefs, that makes by-name lookups in the debugger more reliable. And whenever we can avoid by-name lookups, period, that makes the debug interface more reliable.
   
   
2. Some compilers discard typedef information. They just toss away the typedef name and define the variable as having the underlying type of the typedef. For example, with "typedef int foo_t; foo_t foo;", the type of "foo" would be "int", not "foo_t", so whatever semantics were associated with "foo_t" would be lost.
   
   
3. There is a heavy, language-specific aspect to types. Consider Fortran, where there are no typedefs. Keying the debugging interface to the type of objects probably means that there is a separate way to handle each type of object. For example, the type of a C/C++ communicator variable is probably different than a Fortran communicator variable. I'm not sure what we're going to do about Fortran in the MPI Handles interface given that most MPI objects in Fortran are probably integers.
   

Cheers, John D.