[mpiwg-tools] [Omp-tools] Tool initialization question

[John Mellor-Crummey]

Martin,

> [For MPI] We therefore picked an approach where the tool registers itself once it gets invoked somehow (e.g., in library initialization routines) and then MPI can do the actual initialization of all registered tools during MPI_Init. This allows as many tools to register themselves as needed.
> 
> However, when I brought this up at the last OMPT call, you mentioned that this would cause problem with linking since the runtime system may not be visible, yet, when the registration call gets loaded. When we talked about this today, it wasn’t clear to us anymore, though, why this would be a problem, since the call the registration function simply could load the runtime (assuming its a shared library). Can you elaborate a bit more of why this is problematic?

Here’s why we chose the design for OpenMP where the OpenMP library invokes a function that the tool provides:

The initial design for the OpenMP Tools API had the library publish various routines as part of its API (e.g., ompt_set_callback) and the tool would invoke these operations to register itself. When we tried using this design to profile UMT - an OpenMP application written at LLNL, this approach failed. The attached document has the details. 

I would be happy to elaborate or provide test cases to explain the problem further, if there are unresolved questions from the MPI tools group. The issue described in the attached document may not be a problem in practice for MPI applications. The ingredients that would cause the problem are (1) the MPI library is not linked into an executable, (2) the executable dlopens  a dynamically loaded library that uses MPI. In that case, a preloaded tool wouldn’t be able to see the MPI library and register itself because of dynamic library symbol visibility rules. 

--
John Mellor-Crummey         Professor
Dept of Computer Science    Rice University
email: johnmc at rice.edu      phone: 713-348-5179

> On Jul 2, 2015, at 11:55 AM, Schulz Martin <schulzm at llnl.gov> wrote:
> 
> Oops, my autocomplete caught the old MPI list name.
> 
> Please reply to this email not the first one.
> 
> Thanks!
> 
> Martin
> 
> 
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov <mailto:schulzm at llnl.gov>, http://scalability.llnl.gov/ <http://scalability.llnl.gov/>
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> 
> 
> From: Schulz Martin <schulzm at llnl.gov <mailto:schulzm at llnl.gov>>
> Date: Thursday, July 2, 2015 at 9:50 AM
> To: John Mellor-Crummey <johnmc at rice.edu <mailto:johnmc at rice.edu>>
> Cc: ext-omptools <omp-tools at openmp.org <mailto:omp-tools at openmp.org>>, MPI3 Tools Tools <mpi3-tools at lists.mpi-forum.org <mailto:mpi3-tools at lists.mpi-forum.org>>
> Subject: [Omp-tools] Tool initialization question
> 
> Hi John,
> 
> (I am cc-ing both the MPI and the OMP tool lists, since this affects both – sorry for any duplicate emails this will cause)
> 
> We had an MPI tools group call this morning and talked once again about tool initialization. The current proposals for the two standards are currently different:
> 
> In OpenMP, we rely on a known symbol that the OpenMP runtime looks for and then calls when it is ready to initialize the tool. We talked about this for MPI, but didn’t go with it, since this prevents the ability to allow multiple tools.
> 
> We therefore picked an approach where the tool registers itself once it gets invoked somehow (e.g., in library initialization routines) and then MPI can do the actual initialization of all registered tools during MPI_Init. This allows as many tools to register themselves as needed.
> 
> However, when I brought this up at the last OMPT call, you mentioned that this would cause problem with linking since the runtime system may not be visible, yet, when the registration call gets loaded. When we talked about this today, it wasn’t clear to us anymore, though, why this would be a problem, since the call the registration function simply could load the runtime (assuming its a shared library). Can you elaborate a bit more of why this is problematic?
> 
> Anyone else remember details on this and wants to comment as well? If the registration option doesn’t work is there a third way that we could adopt for both standards that fulfills all criteria?
> 
> Thanks!
> 
> Martin
> 
> 
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov <mailto:schulzm at llnl.gov>, http://scalability.llnl.gov/ <http://scalability.llnl.gov/>
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
> 
> !DSPAM:8504,55956d1417521104631228!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20150702/2426fbb8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OMPT-Initialization.pdf
Type: application/pdf
Size: 63484 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20150702/2426fbb8/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20150702/2426fbb8/attachment-0003.html>