Previous: dotdebug_gdb_scripts section, Up: Auto-loading
Given the multiple ways of auto-loading Python scripts, it might not always be clear which one to choose. This section provides some guidance.
Benefits of the -gdb.py way:
Scripts specified in the .debug_gdb_scripts
section are searched for
in the source search path.
For publicly installed libraries, e.g., libstdc++, there typically
isn't a source directory in which to find the script.
Benefits of the .debug_gdb_scripts
way:
Scripts for libraries done the -gdb.py way require an objfile to trigger their loading. When an application is statically linked the only objfile available is the executable, and it is cumbersome to attach all the scripts from all the input libraries to the executable's -gdb.py script.
Some classes can be entirely inlined, and thus there may not be an associated shared library to attach a -gdb.py script to.
In some circumstances, apps can be built out of large collections of internal
libraries, and the build infrastructure necessary to install the
-gdb.py scripts in a place where gdb can find them is
cumbersome. It may be easier to specify the scripts in the
.debug_gdb_scripts
section as relative paths, and add a path to the
top of the source tree to the source search path.