Next: Which flavor to choose?, Previous: objfile-gdbdotext file, Up: Auto-loading extensions

#### 23.4.2 The `.debug_gdb_scripts` section

For systems using file formats like ELF and COFF, when gdb loads a new object file it will look for a special section named `.debug_gdb_scripts`. If this section exists, its contents is a list of NUL-terminated names of scripts to load. Each entry begins with a non-NULL prefix byte that specifies the kind of entry, typically the extension language.

gdb will look for each specified script file first in the current directory and then along the source search path (see Specifying Source Directories), except that `$cdir` is not searched, since the compilation directory is not relevant to scripts.

Entries can be placed in section `.debug_gdb_scripts` with, for example, this GCC macro for Python scripts.

         /* Note: The "MS" section flags are to remove duplicates.  */
         #define DEFINE_GDB_PY_SCRIPT(script_name) \
           asm("\
         .pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n\
         .byte 1 /* Python */\n\
         .asciz \"" script_name "\"\n\
         .popsection \n\
         ");

For Guile scripts, replace `.byte 1` with `.byte 3`. Then one can reference the macro in a header or source file like this:

         DEFINE_GDB_PY_SCRIPT ("my-app-scripts.py")

The script name may include directories if desired.

Note that loading of this script file also requires accordingly configured `auto-load safe-path` (see Auto-loading safe path).

If the macro invocation is put in a header, any application or library using this header will get a reference to the specified script, and with the use of `"MS"` attributes on the section, the linker will remove duplicates.