RE: [PATCH] gdb: use NT_386_TLS regset to access TLS GDT entries on i386 Linux

["Joos, Christina" <christina.joos@intel.com>]

 -----Original Message-----
> From: Simon Marchi <simon.marchi@efficios.com>
> Sent: Dienstag, 29. September 2026 16:23
> To: Joos, Christina <christina.joos@intel.com>; Andrew Burgess
> <aburgess@redhat.com>; gdb-patches@sourceware.org
> Subject: Re: [PATCH] gdb: use NT_386_TLS regset to access TLS GDT entries on
> i386 Linux
> 
> 
> 
> On 2026-09-29 07:38, Joos, Christina wrote:
> >> -----Original Message-----
> >> From: Andrew Burgess <aburgess@redhat.com>
> >> Sent: Dienstag, 29. September 2026 11:38
> >> To: Simon Marchi <simon.marchi@efficios.com>;
> >> gdb-patches@sourceware.org
> >> Cc: Simon Marchi <simon.marchi@efficios.com>
> >> Subject: Re: [PATCH] gdb: use NT_386_TLS regset to access TLS GDT
> >> entries on
> >> i386 Linux
> >>
> >> Simon Marchi <simon.marchi@efficios.com> writes:
> >>
> >>> 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.

This is my understanding as well when looking at ptrace.c in the current Linux kernel repository.
So I believe Claude is right here, although I am not a kernel developer.

> >>>
> >>> 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.

I verified these configs for gdb.arch/i386-tls-regs.exp:

- 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

But I did save myself the time of compiling an i386 kernel this time.

> >>> This is a regression in GDB 18, so this patch would need to be
> >>> cherry-picked to the gdb-18-branch.
> >>
> >> Thanks for fixing this, and for the well written commit message.
> >>
> >> Just today someone emailed me off-list reporting this problem:
> >>
> >>
> >>
> https://inbox.sourceware.org/binutils/CAG_eJLe_vuR93fE6H4hENPh3=R2XE7
> >> 2
> >> T2tL1ZaTnY93zW2J5-Q@mail.gmail.com
> >>
> >> which did make it to the gdb-help list via a CC on a follow up post,
> >> but unfortunately never made it into a release blocking bug.  The
> >> issue here is that PTRACE_GET_THREAD_AREA and
> PTRACE_SET_THREAD_AREA
> >> don't exist for older glibc, they were added in glibc 2.27 I believe,
> >> which is after the glibc 2.23 the bug was reported against.
> >>
> >> The NT_386_TLS that this patch uses instead was added in glibc 2.10,
> >> so this patch should fix that build issue problem on older glibc too.
> >>
> >> For both master and gdb-18-branch:
> >>
> >> Approved-By: Andrew Burgess <aburgess@redhat.com>
> >>
> >> Thanks,
> >> Andrew
> >
> > I plan to look at this in a few hours, but since Andrew has already approved it,
> it's of course fine with me if you go ahead.
> > This is probably a bit urgent.
> 
> You can take the time to review it, it won't make a difference whether we
> merge this today or later this week.
> 
> > Since x32 is mentioned here, just FYI, in case you haven't seen it:
> > https://www.phoronix.com/news/Linux-x32-ABI-2026
> 
> Indeed, I just looked into it because someone mentioned it in the bug.

Thanks a lot for this patch. I have nothing to add; it looks all good to me.

I also learned quite a lot while looking at this.

Approved-By: Christina Joos <christina.joos@intel.com>

Christina

________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.