Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>There is no circular dependence here. Rather you are facing two different methods that place the Valgrind client requests in different places.</p> <p>Open MPI can be built with OMPI-specific Valgrind support. This differs from building Memchecker with MPI support in that it also allows OMPI internals to be checked (that's why it also requires that you enable debugging in OMPI). The Memchecker client requests become part of the library code in a very OMPI-specific way. This does not require changes to the Valgrind code, i.e. it should work with any Valgrind installation (given that the minimum version requirement is satisfied)</p> <p>On the other side, Open MPI as well as any other MPI implementation, provides the <code>PMPI</code> profiling interface. This could be used by Memchecker to provide <em>generic MPI support</em>. As described in the documentation, Memchecker builds a library of functions that replace (and wrap) the original MPI calls (this is how the <code>PMPI</code> mechanism works - all <code>MPI_*</code> calls are weak symbols and can be overridden by other symbols of the same name, the true MPI calls are actually <code>PMPI_*</code> and <code>MPI_*</code> are defined to be weak aliases on ELF systems). This does not require changes to the MPI library code. It should work with any MPI implementation, but only user memory would be correctly debugged, i.e. false positives might be detected inside the MPI library code (although those need not be false positives and could mean that the library itself is buggy).</p> <p>The same goes for Valgrind support in MPICH.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload