Debian Patches

Status for gdb/18.1-3

Patch Description Author Forwarded Bugs Origin Last update
load-versioned-libcc1.patch load-versioned-libcc1
* d/p/load-versioned-libcc1.patch:
- load libcc1.so.0 instead unversioned file.		 Hector Oron <zumbi@debian.org> no 2019-02-20
fix-blhc-libiberty.patch libiberty: Pass LDFLAGS
Avoid blhc false positive:

LDFLAGS missing (-Wl,-z,relro): \ mv -f /builds/gdb-team/gdb/debian/output/source_dir/debian/tmp/usr/lib/`x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/builds/gdb-team/gdb/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -print-multi-os-directory`/./libiberty.an /builds/gdb-team/gdb/debian/output/source_dir/debian/tmp/usr/lib/`x86_64-linux-gnu-gcc -g -O2 -ffile-prefix-map=/builds/gdb-team/gdb/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -print-multi-os-directory`/./libiberty.a		 Ricardo Ribalda <ricardo@ribalda.com> no 2023-12-04
fix-blhc-chew.patch fix-blhc-chew
===================================================================		 Héctor Orón Martínez <zumbi@debian.org> no 2025-01-11
gfdl-dont-build-manpages.patch gfdl-dont-build-manpages Héctor Orón Martínez <zumbi@debian.org> not-needed Debian 2024-07-27
cross.patch gdb fails to cross build from source for three distinct reasons. [...]
3. In bfd/doc, chew.c uses host compiler flags with the build compiler.
This fails badly when compiling for amd64 or arm64.		 Helmut Grohne <helmut@subdivi.de> invalid debian
0001-gdb-use-NT_386_TLS-regset-to-access-TLS-GDT-entries-.patch gdb: use NT_386_TLS regset to access TLS GDT entries on i386 Linux

Bug 34678 reports that a 32-bit GDB running on an x86-64 kernel can't
make inferior function calls:

(gdb) p f()
Couldn't get TLS area data: Invalid argument.

This happens because GDB fails to read the special registers holding the
TLS GDT entries, added in commit 91eee81d2353 ("gdb: include NT_I386_TLS
note in generated core files", 2025-11-20).

The failure isn't specifically related to inferior function calls, but
it is most visible there when GDB attempts to save all registers prior
to a function call.

These "registers" are read using

ptrace (PTRACE_GET_THREAD_AREA, pid, addr, data)

where `addr` is not an address, but the index of a GDT entry to read.
The valid indices depend on the arch of the kernel. For an i386 kernel,
the valid range is [6, 8], while for an x86-64 kernel, the valid range
is [12, 14].

As commit 91eee81d2353 properly noted, the indices really depend on the
kernel, not on how GDB or the inferior program were built. On an x86-64
kernel, even when GDB and/or the inferior are 32-bit programs, we need
to query the x86-64 indices:

/* This constant defines the first GDT (Global Descriptor Table) entry
that the kernel allocates for holding TLS descriptors. There are three
entries, starting at this index which can be accessed using the
PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA ptrace calls. This
constant is only valid for true i386 kernels. For amd64 kernels
running in 32-bit mode (i.e. executables compiled -m32) there is a
different constant, see nat/amd64-linux.h. */

However, the implementation isn't quite right, since it bases the
decision on whether GDB itself is a 32-bit or 64-bit program. So we get
it wrong when GDB is a 32-bit program, debugging a 32-bit program, on a
64-bit kernel. GDB queries the i386 indices, which gets an EINVAL
reply, because it should have used the x86-64 indices.

Also, according to Claude (I couldn't test since I don't have a machine
with x32 userland), PTRACE_GET_THREAD_AREA and PTRACE_SET_THREAD_AREA
are not supported for x32 tracers: the kernel's x32_arch_ptrace doesn't
handle them, so they would fail with EIO. An x32 GDB debugging an i386
program therefore couldn't read the TLS registers either.

Fix both problems by using the NT_386_TLS regset instead, with
PTRACE_GETREGSET and PTRACE_SETREGSET. This regset contains the three
TLS GDT entries, so accessing it doesn't require knowing their indices.
When reading, the kernel fills the entry_number field of each entry with
the right index. When writing, it ignores the entry_number fields.
This is the same data as the NT_386_TLS core file note, which these
registers are used to produce.

This also makes it possible to read the three entries with a single
ptrace call, instead of three.

Remove the i386_initial_tls_gdt constants, which are now unused, along
with nat/amd64-linux.h, which only contained one of them.

Tested by running gdb.arch/i386-tls-regs.exp on all these
configurations:

- x86-64 kernel, 64-bit GDB, native
- x86-64 kernel, 64-bit GDB, gdbserver
- x86-64 kernel, 32-bit GDB, native
- x86-64 kernel, 32-bit GDB, gdbserver
- i386 kernel, 32-bit GDB, native
- i386 kernel, 32-bit GDB, gdbserver

This test would previously fail in the "x86-64 kernel, 32-bit GDB"
configs.

This is a regression in GDB 18, so this patch would need to be
cherry-picked to the gdb-18-branch.

(cherry picked from commit ebe0d2663a1cb739e797cdbb1d102151a089fa0f)		 Simon Marchi <simon.marchi@efficios.com> yes upstream 2026-09-28

All known versions for source package 'gdb'

Links