Hi Marc-Andre, On Sep 30, 2011, at 6:27 AM, Marc-Andre Hermanns wrote:

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?

I agree - as long as we can generate a full list of names, we can intercept them all. Adding wrappers shouldn't be a problem.

...

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.

I agree - this is remarkable.

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?

That is a question for the Fortran experts.

...

* 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?

Also, here, I think the Fortran experts need to weigh in.

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.

I thought that was just for the argument checking in mpif.h and that we decided to not support this. Are there more locations were the names are too long?

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?

Yes, if we do have to shorten names, I agree - I think, though, we got around the issue, or did we not?

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.

Yes, that would be great - all are cc-ed. Martin

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

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA