[Mpi3-tools] Current Version of the MPIR document

[John DelSignore]

Hi Ashley,

Look here:

http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/mpich-attach.txt

Line 138:

"
Totalview also needs the debug information for the MPIR_PROCDESC type,
since it uses that to work out the size and fields in the procedesc
array. 
"

And if you don't believe me, ask your father-in-law! ;-)

Cheers, John D.


Ashley Pittman wrote:
> On 28 Jun 2010, at 22:35, John DelSignore wrote:
>>> Like the original work this document specifies a definition for MPIR_PROCDESC, it however then goes on to say that the definition isn't fixed but rather is up to the implementation.
>>>
>>> typedef struct {
>>>  char *host_name;
>>>  char *executable_name;
>>>  int pid;
>>> } MPIR_PROCDESC;
>>>
>>> Section 9.2 paragraph 4:
>>> The pid member is the integer process identifier of the MPI process. Note that historically pid was defined as a C language int, which is an integer of an unknown size, which might be smaller than the size of a process identifier for the target system. Implementations should define pid as an integer size that is large enough to hold a process identifier for the target system. For example, implementations should use pid_t as the type of pid provided that pid_t is an integer type.
>> I believe that that paragraph is accurate. The intent of MPIR has always been that the layout and sizes of the fields in MPIR_PROCDESC and the size of MPIR_PROCDESC itself are communicated through the debug information, and that the offsets and sizes were not hard-coded into the debugger. It was done this way for portability and to allow MPI implementations to rearrange the fields or toss extra fields into the structure.
> 
> I have to disagree based on the contents of the original header file.  This information is repeated on the ANL webpage where the header file is hosted, apologies for formatting here:
> 
> http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/attach.h.html
> 
> /* A little struct to hold the target processor name and pid for
>  * each process which forms part of the MPI program.
>  * We may need to think more about this once we have dynamic processes...
>  *
>  * DO NOT change the name of this structure or its fields. The debugger knows
>  * them, and will be confused if you change them.
>  */
> 
> typedef struct
>  {
>   char * host_name;           
> /* Something we can pass to inet_addr */
> 
>   char * executable_name;     
> /* The name of the image */
> 
>   int    pid;		      
> /* The pid of the process */
> 
> } MPIR_PROCDESC;
> 
> http://www.mcs.anl.gov/research/projects/mpi/mpi-debug/
> 
> MPIR_proctable
> This is an array of structures with type
> typedef struct {
>   char * host_name;           /* Something we can pass to inet_addr */
>   char * executable_name;     /* The name of the image */
>   int    pid;		      /* The pid of the process */
> } MPIR_PROCDESC;
> 
>>> Are there MPI librarys in existence which don't use int as the type for pid?
>> I don't know, but I'd guess there could be. I have some vague recollection that on Cray Catamount, pids were 64-bit and MPI was supported, so it's likely that MPI used 64-bit pids. Also, I think that IRIX has 64-bit pids, but SGI MPI didn't use the MPIR interface, they used "array services".
>>
>>> I've certainly not seen any and never seen it necessary to read the type of MPIR_PROCDESC because it's type is well specified.
>> Just because you haven't seen any doesn't mean that they don't exist. You've been cheating and getting away with it.
> 
> Obviously the rest of my argument rests on the initial premise being true.
> 
> Ashley,
>