<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I wanted to write the following down, while it was fresh in my mind...<br>
<br>
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.<br>
<br>
Here is the short list of problems we've encountered in the past with
typedefs (and types in general):<br>
<ol>
<li>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</li>
<li>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.<br>
<br>
</li>
<li>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.<br>
</li>
</ol>
Cheers, John D.<br>
<br>
</body>
</html>