Given the multiple ways of auto-loading extensions, it might not always be clear which one to choose. This section provides some guidance.
Benefits of the -gdb.ext 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
Scripts for libraries done the -gdb.ext 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.ext script.
Some classes can be entirely inlined, and thus there may not be an associated shared library to attach a -gdb.ext 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.ext 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.