From: Hannes Domani <ssbssa@yahoo.de>
To: gdb-patches@sourceware.org
Subject: Re: [PING] [PATCH v2] Implement native TLS support on Windows
Date: Fri, 22 May 2026 14:00:39 +0200 [thread overview]
Message-ID: <013b908c-f11f-43d0-b9e3-5f336c8845ea@yahoo.de> (raw)
In-Reply-To: <20260509132633.1089523-1-ssbssa@yahoo.de>
Ping.
On 5/9/26 15:24, Hannes Domani wrote:
> GCC 16 introduced native TLS variables on Windows, so this adds
> debugger support for them.
>
> The fetch_tls_load_module_address gdbarch method is used to get the
> address of _tls_index of the OBJFILE, which is then forwarded as LM_ADDR
> to windows_get_thread_local_address.
>
> The TLS slot for a module can be found in
> TIB->thread_local_storage[_tls_index].
> ---
> Changes in v2:
> - added NEWS entry
> - more comments
> - split up if()-conditions in windows_get_thread_local_address
> ---
> gdb/NEWS | 2 ++
> gdb/windows-tdep.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/gdb/NEWS b/gdb/NEWS
> index 480e1854002..ee1a21179b5 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -78,6 +78,8 @@
> * The Windows native target now supports non-stop mode. This feature
> requires Windows 10 or later.
>
> +* Support for native Thread Local Storage (TLS) variables on Windows.
> +
> * New targets
>
> GNU/Linux/MicroBlaze (gdbserver) microblazeel-*linux*
> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c
> index 38ee1d7275e..78bf49b9c81 100644
> --- a/gdb/windows-tdep.c
> +++ b/gdb/windows-tdep.c
> @@ -954,6 +954,73 @@ windows_init_abi_common (struct gdbarch_info info, struct gdbarch *gdbarch)
> set_gdbarch_get_siginfo_type (gdbarch, windows_get_siginfo_type);
> }
>
> +/* Implement the fetch_tls_load_module_address gdbarch method.
> + Usually this method returns an address representing a load module, but this
> + doesn't exist on Windows. Instead it returns the address of the
> + "_tls_index" variable of OBJFILE, which is then forwarded as LM_ADDR
> + in windows_get_thread_local_address below. */
> +
> +static CORE_ADDR
> +windows_tls_index_address (struct objfile *objfile)
> +{
> + bound_minimal_symbol minsym
> + = lookup_minimal_symbol_linkage ("_tls_index", objfile, false);
> + if (minsym.minsym == nullptr)
> + throw_error (TLS_GENERIC_ERROR, _("Cannot find address of _tls_index"));
> +
> + return minsym.value_address ();
> +}
> +
> +/* Implement the get_thread_local_address gdbarch method.
> + Each module (with TLS variables) gets its own TLS slot represented by
> + _tls_index, which can be found in TIB->thread_local_storage[_tls_index].
> + The address of _tls_index is provided by the LM_ADDR argument. */
> +
> +static CORE_ADDR
> +windows_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid,
> + CORE_ADDR lm_addr, CORE_ADDR offset)
> +{
> + int ptr_bytes;
> + int tls_offset; /* Offset of thread_local_storage in TIB. */
> + if (gdbarch_ptr_bit (gdbarch) == 32)
> + {
> + ptr_bytes = 4;
> + tls_offset = 44;
> + }
> + else
> + {
> + ptr_bytes = 8;
> + tls_offset = 88;
> + }
> +
> + gdb_byte buf[8];
> + if (target_read_memory (lm_addr, buf, 4))
> + throw_error (TLS_GENERIC_ERROR, _("Cannot read _tls_index"));
> +
> + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> + uint32_t tls_index = extract_unsigned_integer (buf, 4, byte_order);
> +
> + CORE_ADDR tlb;
> + if (!target_get_tib_address (ptid, &tlb))
> + throw_error (TLS_GENERIC_ERROR, _("Cannot get tib address"));
> +
> + if (target_read_memory (tlb + tls_offset, buf, ptr_bytes))
> + throw_error (TLS_GENERIC_ERROR, _("Cannot read thread_local_storage"));
> +
> + CORE_ADDR tls_ptr = extract_unsigned_integer (buf, ptr_bytes, byte_order);
> + if (tls_ptr == 0)
> + throw_error (TLS_NOT_ALLOCATED_YET_ERROR, _("TLS not allocated yet"));
> +
> + if (target_read_memory (tls_ptr + tls_index * ptr_bytes, buf, ptr_bytes))
> + throw_error (TLS_GENERIC_ERROR, _("Cannot read TLS slot"));
> +
> + CORE_ADDR slot_ptr = extract_unsigned_integer (buf, ptr_bytes, byte_order);
> + if (slot_ptr == 0)
> + throw_error (TLS_NOT_ALLOCATED_YET_ERROR, _("TLS slot not allocated yet"));
> +
> + return slot_ptr + offset;
> +}
> +
> /* See windows-tdep.h. */
> void
> windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> @@ -963,6 +1030,12 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>
> /* On Windows, "long"s are only 32bit. */
> set_gdbarch_long_bit (gdbarch, 32);
> +
> + /* Enable TLS support. */
> + set_gdbarch_fetch_tls_load_module_address (gdbarch,
> + windows_tls_index_address);
> + set_gdbarch_get_thread_local_address (gdbarch,
> + windows_get_thread_local_address);
> }
>
> /* See windows-tdep.h. */
next prev parent reply other threads:[~2026-05-22 12:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260509132633.1089523-1-ssbssa.ref@yahoo.de>
2026-05-09 13:24 ` Hannes Domani
2026-05-09 13:40 ` Eli Zaretskii
2026-05-22 12:00 ` Hannes Domani [this message]
2026-05-22 13:49 ` Tom Tromey
2026-05-23 9:51 ` Hannes Domani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=013b908c-f11f-43d0-b9e3-5f336c8845ea@yahoo.de \
--to=ssbssa@yahoo.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox