Previous: dotdebug_gdb_scripts section, Up: Auto-loading extensions [Contents][Index]

#### 23.4.3 Which flavor to choose?

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:

- Can be used with file formats that don’t support multiple sections.
- Ease of finding scripts for public libraries.

  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.

- Doesn’t require source code additions.

Benefits of the `.debug_gdb_scripts` way:

- Works with static linking.

  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.

- Works with classes that are entirely inlined.

  Some classes can be entirely inlined, and thus there may not be an associated shared library to attach a `-gdb.ext` script to.

- Scripts needn’t be copied out of the source tree.

  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.