[Mpi3-tools] Questions on the F2008 profiling interface issues

[Marc-Andre Hermanns]

Martin,

> I was in Dresden the last few days (visiting the Vampir group, in
> particular Andreas Knuepfer and Tobias Hilbrich who are responsible for
> their MPI wrappers) and we sat down to talk about the issues around the
> profiling interface in ticket #229.
> 
> Here is a quick summary with a few questions that came up:
> 
> * With the new Fortran symbol naming variants, there are 6 or 8 or 10
> versions for every MPI subroutine. Tools could intercept all versions by
> providing own symbols for all versions. 

If it is clear which name the symbols have, additional symbol names
should be easy to generate, so at this stage I think it doesn't matter
much, whether we have 6, 8, or 10 different schemes to cover. Right?

> Now the problem: Within the wrapper function a tool needs to call the
> correct PMPI call which usually is the same prefix (either '_f08',
> '_f', '__' etc.) as the MPI call it is in. A mapping to matching C
> functions (as most tools do it now) is not possible due to problems
> with calling conventions for callback routines.

As far as I know our wrappers call the C routines, because we jump
through all sorts of hoops to get a proper Fortran to C conversion and
back. So in this regard, we need to fix this. Interestingly this has not
popped up yet.

If we write Fortran wrappers in Fortran, how would a Fortran wrapper
compiled with Fortran 77 have to call the C measurement code inside the
wrapper? If the Fortran compiler implicitly adds underscores to the
calls, do I have to provide a special Fortran interface to my
measurement system then?

> * Would the following solution work? All wrappers for Fortran are written
> in Fortran instead of C. 
> [...]
> For every MPI function, there are 6 or 8 variants and all of them
> need to be provided by a tool. This would probably mean that we have
> to compile wrappers with all three calling conventions (mpif.h, use
> mpi_f and use mpi_f08) and then link them together?

Don't we need to compile with all three calling conventions on all
possible compilers on a given system?

We currently provide all 4 name-mangling schemes with every install of
Scalasca, because we had some issues with applications using two
different Fortran compilers for different sub-modules. (This came up in
a project some years back, and ever since then we provide all schemes in
the same library and it seems to work.)

> * As discussed at the forum, if we want to keep our tools in C (which is
> probably still the easier and better option), we need to know the symbols
> on the "p" side and we need a portable way to figure this out. We talked
> about the solution of two groups of routines - one for which we have _f08
> symbols for one for which we don't. Rolf, how will you add this to the
> standard, in particular how will you form those groups.

I started to get some doubts about this approach. One of the issues was
that some choice-buffer routines had names longer than the proposed
limit. So they need to be mangled differently, especially, their symbol
needs to be shortened. And as I understood it, the current idea is to
leave it to the MPI implementation to define the shortened name.

It is one thing, finding out which suffix is used. Finding how function
names are mangled without any form of restricting to possible schemes
seems to be another ball game?

Am I missing something?

I think, as it was pointed out in Santorini with the Fortran Bindings in
general, we (or at least I) don't have enough Fortran expertise to think
this through all to the end and consider all implications. I think it
would be a great benefit to have people of the Fortran WG to join on the
call on Monday. I hope this is possible.

Cheers,
Marc-Andre
-- 
Marc-Andre Hermanns
German Research School for
Simulation Sciences GmbH
c/o Laboratory for Parallel Programming
52056 Aachen | Germany

Tel +49 241 80 99753
Fax +49 241 80 6 99753
Web www.grs-sim.de

Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
Registered in the commercial register of the local court of
Düren (Amtsgericht Düren) under registration number HRB 5268
Registered office: Jülich
Executive board: Prof. Marek Behr Ph.D. | Dr. Norbert Drewes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4524 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20110930/589862f8/attachment-0001.bin>