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: [email protected] phone: 713-348-5179
On Jul 2, 2015, at 11:55 AM, Schulz Martin <[email protected]> wrote:
Oops, my autocomplete caught the old MPI list name.
Please reply to this email not the first one.
Thanks!
Martin
________________________________________________________________________ Martin Schulz, [email protected] <mailto:[email protected]>, http://scalability.llnl.gov/ <http://scalability.llnl.gov/> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
From: Schulz Martin <[email protected] <mailto:[email protected]>> Date: Thursday, July 2, 2015 at 9:50 AM To: John Mellor-Crummey <[email protected] <mailto:[email protected]>> Cc: ext-omptools <[email protected] <mailto:[email protected]>>, MPI3 Tools Tools <[email protected] <mailto:[email protected]>> 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, [email protected] <mailto:[email protected]>, http://scalability.llnl.gov/ <http://scalability.llnl.gov/> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
!DSPAM:8504,55956d1417521104631228!