Filtering dlopen Events
Typically, TotalView processes all dynamic shared libraries as they are loaded, looking for locations where breakpoints need to be planted and processing debug symbols in order to give developers the most information about their application. This processing takes time and can greatly slow down the startup of the debugger. This extra work may be unnecessary if no breakpoints need to be planted in the shared libraries.
Filtering dlopen events may be particularly beneficial when using Open MPI or other highly dynamic runtime libraries.
TotalView provides two dlopen state variables and related command line options to defer planting breakpoints in dynamically loaded libraries until the process stops for some other reason. Deferring dlopen event processing allows the debugger to handle all dynamically loaded shared libraries at the same time, which is much more efficient than handling them serially.
Use these state variables to configure a dynamic library processing mode of either Fast, Medium, or Slow.
In Fast mode, the process never stops for a dlopen event, not even for "null" dlopen events. Using this option can result in significant performance gains, but may be impractical for some applications because any breakpoints in a dynamic library won’t be enabled until later in program execution. In Medium mode, some libraries can be specified to either immediately reevaluate or defer evaluation of breakpoint specifications, rather than all or none. This allows for a more fine grained approach in processing library symbols and setting breakpoints in order to stop early in program execution. In Slow mode, every dlopen event results in the immediate reevaluation of breakpoint specifications. For detail, see “Filtering dlopen Events” in the TotalView Reference Guide.
