Build2 publishers3 min readPublished
GDB 18.1 asks for existing .gdb_index sections to be regenerated after a type-lookup fix
GDB 18.1 adds every type symbol to .gdb_index to fix failed type lookups, and its notes say existing indexes should be regenerated. Teams that pin the debugger in CI should rebuild those indexes with it and retest any script that parses Windows paths.
The Engineer · Build desk

What happened
- GDB 18.1 is out; the GNU Debugger covers Ada, C, C++, Fortran, Go and Rust and targets more than a dozen processor architectures.
- GDB now writes every type symbol into the .gdb_index section, fixing type lookups that could fail when GDB relied on the index.
- On Windows, GDB now shows file names with forward slashes only, in the CLI, TUI, GDB/MI and DAP interfaces alike.
- The Windows native target gains non-stop mode on Windows 10 or later, a working scheduler-locking setting, and native thread-local storage variables.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Bumping a pinned GDB in a CI image leaves indexes written by older builds untouched, so teams have to decide whether to rebuild those artifacts in the same change.
- exposure Test harnesses and IDE integrations that match Windows paths or scrape info locals text will get different strings after the upgrade and can fail on them.
- capability Windows CI jobs on Windows 10 or later hosts can now run non-stop and scheduler-locking debugging tests against the native target.
GDB 18.1 now puts all type symbols into the .gdb_index section [2]. According to the release notes, the change fixes cases where GDB "could fail to find a type when relying on the index." The next line says: "Existing indexes should be regenerated." [2]
The upgrade costs time at the regeneration step. If a build step writes the index into shipped binaries or debug-info files, that index came from whichever GDB the build image pinned. Installing a newer debugger to read it does not rewrite it. The notes do not say whether 18.1 recovers the missing types from an older index [2]. I would treat old indexes as incomplete and rebuild them in the same change that moves the pin.
The second thing to test is output. The notes give a Windows example: "C:/proj/src\main.c" now appears as "C:/proj/src/main.c" everywhere GDB prints a file or directory name [3]. A harness that compares breakpoint locations against the mixed-slash form will fail on the new string. On Windows Terminal, when the output codepage is 65001, GDB now sets the host charset to UTF-8 by itself and turns on emoji styling [17]. I have yet to see a CI log that wanted emoji. On every host, `info locals` now adds a "shadowed" annotation and location information for variables that shadow others or are shadowed by them [18]. `info inferiors` now shows any loaded core file [19]. Any script that scrapes CLI text needs a diff against 18.1 output.
Phoronix wrote that Windows "is seeing a lot of love" in this release [16], and it also reports a new AArch64 MinGW target [5]. The change I would single out is smaller. The `add-inferior`, `clone-inferior` and MI `-add-inferior` commands used to tend to crash GDB when asked to share a connection that cannot be shared, such as a core file or the Windows native target [6]. In 18.1 they print a warning and create the new inferior without a connection [6].
Launch wrappers get new options. `--no-escape-args` is an alternative to `--args` that does not escape special shell characters, and gdbserver accepts the same flag [7]. Quoted arguments to `set args`, `run`, `start` and `starti` may now contain a newline [7]. If a remote server supports the new qExecAndArgs packet, GDB copies the server's argument string into its own args setting. `show args` then displays it, and later runs reuse it [8]. On extended-remote targets, GDB can now set `remote exec-file` from the current executable when neither the server nor the user supplied one [9]. Serial connections accept arbitrary baud rates on systems whose libc takes them through cfsetispeed/cfsetospeed, as glibc 2.42 and later does [14].
Images that build from source can pin the xz tarball, 22MiB, by its sha256, cd9fc3fe2b47743840e42c1592d3d87f8302eb18639c0b8b4ba0898002e2348f [10]. The gzip tarball is 37MiB [10], so it is 15MiB more per fetch [11]. The maintainers say they will post errata notes and host-specific tips as problems come up [12].
What to watch
- Errata notes and host-specific tips the GDB maintainers say they will post for 18.1 as problems come up.
- Whether distributions regenerate .gdb_index in their debug-info packages when they move to 18.1.
- Fixes in Windows IDE frontends that consume GDB/MI or DAP paths, if the forward-slash change breaks their path matching.