* [PATCH v6 01/11] Don't attempt to find TLS address when target has no registers
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 02/11] Allow TLS access to work in gdb.server/no-thread-db.exp Kevin Buettner
` (10 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This commit fixes two bugs, one of which is Bug 25807, which occurs
when target_translate_tls_address() is called from
language_defn::read_var_value in findvar.c. I found it while testing on
aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local
into a FAIL due to a GDB internal error. Now, with this commit in place,
the KFAIL/FAIL turns into a PASS.
In addition to the existing test just noted, I've also added a test to
the new test case gdb.base/tls-nothreads.exp. It'll be tested, using
different scenarios, up to 8 times:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: after exit: print tls_tbss_1
There is a related problem that occurs when target_translate_tls_address
is called from find_minsym_type_and_address() in minsyms.c. It can be
observed when debugging a program without debugging symbols when the
program is not executing. I've written a new test for this, but it's
(also) included in the new test case gdb.base/tls-nothreads.exp, found
later in this series. Depending on the target, it can run up to 8
times using different scenarios. E.g., on aarch64, I'm seeing these
PASSes, all of which test this change:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
In an earlier version of this commit (v4), I was checking whether the
target has registers in language_defn::read_var_value in findvar.c and
in find_minsym_type_and_address in minsyms.c, printing suitable error
messages in each case. In his review of this commit for the v4
series, Tom Tromey asked whether it would be better to do this check
in target_translate_tls_address. I had considered doing that for the
v4 (and earlier) series, but I wanted to print slightly different
messages at each check. Also, read_var_value in findvar.c was already
printing a message in some cases and I had arranged for the later
check in that function to match the original message.
However, while I had added a target-has-registers check at two of the
call sites for target_translate_tls_address, I hadn't added it at the
third call site which is in dwarf_expr_context::execute_stack_op() in
dwarf2/expr.c. I believe that in most cases, this is handled by the
early check in language_defn::read_var_value...
else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ())
error (_("Cannot read `%s' without registers"), var->print_name ());
...but it's entirely possible that dwarf_expr_context::execute_stack_op()
might get called in some other context. So it makes sense to do the
target-has-registers check for that case too. And rather than add yet
another check at that call site, I decided that moving the check and
error message to target_translate_tls_address makes sense.
I had to make the error messages that it prints somewhat more generic.
In particular, when called from language_defn::read_var_value, the
message printed by target_translate_tls_address no longer matches the
earlier message that could be printed (as shown above). That meant
that the test cases which check for this message, gdb.threads/tls.exp,
and gdb.base/tls-nothreads.exp had to be adjusted to account for the
new message. Also, I think it's valuable to the user to know (if
possible) the name of the variable that caused the error, so I've
added an optional parameter to target_translate_tls_address, providing
the name of the variable, if it's known. Therefore, the message
that's printed when the target-has-registers test fails is one of the
following:
When the TLS variable isn't known (due to being called from
dwarf_expr_context::execute_stack_op):
"Cannot translate TLS address without registers"
When the TLS variable is known (from either of the other two call sites
for target_translate_tls_address):
"Cannot find address of TLS symbol `%s' without registers"
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807
---
gdb/findvar.c | 3 ++-
gdb/minsyms.c | 3 ++-
gdb/target.c | 16 +++++++++++++---
gdb/target.h | 8 +++++++-
gdb/testsuite/gdb.threads/tls.exp | 2 +-
5 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/gdb/findvar.c b/gdb/findvar.c
index 1a9d2bedfc2..8c71d68ed31 100644
--- a/gdb/findvar.c
+++ b/gdb/findvar.c
@@ -485,7 +485,8 @@ language_defn::read_var_value (struct symbol *var,
/* Determine address of TLS variable. */
if (obj_section
&& (obj_section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0)
- addr = target_translate_tls_address (obj_section->objfile, addr);
+ addr = target_translate_tls_address (obj_section->objfile, addr,
+ var->print_name ());
}
break;
diff --git a/gdb/minsyms.c b/gdb/minsyms.c
index 7b03e38de06..daa83325f30 100644
--- a/gdb/minsyms.c
+++ b/gdb/minsyms.c
@@ -1688,7 +1688,8 @@ find_minsym_type_and_address (minimal_symbol *msymbol,
{
/* Skip translation if caller does not need the address. */
if (address_p != NULL)
- *address_p = target_translate_tls_address (objfile, addr);
+ *address_p = target_translate_tls_address
+ (objfile, addr, bound_msym.minsym->print_name ());
return builtin_type (objfile)->nodebug_tls_symbol;
}
diff --git a/gdb/target.c b/gdb/target.c
index 8d7f168db84..210c81f7281 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -1250,11 +1250,21 @@ generic_tls_error (void)
_("Cannot find thread-local variables on this target"));
}
-/* Using the objfile specified in OBJFILE, find the address for the
- current thread's thread-local storage with offset OFFSET. */
+/* See target.h. */
+
CORE_ADDR
-target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
+target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset,
+ const char *name)
{
+ if (!target_has_registers ())
+ {
+ if (name == nullptr)
+ error (_("Cannot translate TLS address without registers"));
+ else
+ error (_("Cannot find address of TLS symbol `%s' without registers"),
+ name);
+ }
+
volatile CORE_ADDR addr = 0;
struct target_ops *target = current_inferior ()->top_target ();
gdbarch *gdbarch = current_inferior ()->arch ();
diff --git a/gdb/target.h b/gdb/target.h
index 760d210aa3b..6b96b049ac0 100644
--- a/gdb/target.h
+++ b/gdb/target.h
@@ -2472,8 +2472,14 @@ extern void target_pre_inferior ();
extern void target_preopen (int);
+/* Using the objfile specified in OBJFILE, find the address for the
+ current thread's thread-local storage with offset OFFSET. If it's
+ provided, NAME might be used to indicate the relevant variable
+ in an error message. */
+
extern CORE_ADDR target_translate_tls_address (struct objfile *objfile,
- CORE_ADDR offset);
+ CORE_ADDR offset,
+ const char *name = nullptr);
/* Return the "section" containing the specified address. */
const struct target_section *target_section_by_addr (struct target_ops *target,
diff --git a/gdb/testsuite/gdb.threads/tls.exp b/gdb/testsuite/gdb.threads/tls.exp
index c6fdb6f944d..1dcf269dd49 100644
--- a/gdb/testsuite/gdb.threads/tls.exp
+++ b/gdb/testsuite/gdb.threads/tls.exp
@@ -159,7 +159,7 @@ gdb_test_multiple "print a_thread_local" "" {
-re -wrap "Cannot find thread-local variables on this target" {
kfail "gdb/25807" $gdb_test_name
}
- -re -wrap "Cannot read .a_thread_local. without registers" {
+ -re -wrap "Cannot (?:read|find address of TLS symbol) .a_thread_local. without registers" {
pass $gdb_test_name
}
}
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 02/11] Allow TLS access to work in gdb.server/no-thread-db.exp
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 01/11] Don't attempt to find TLS address when target has no registers Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 03/11] Track and fetch TLS module ids for MUSL and GLIBC Kevin Buettner
` (9 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
The patches later in the series add GDB-internal TLS support for
certain targets. This commit updates the "print foo" test in
gdb.server/no-thread-db.exp to accept either a TLS failure (when
libthread_db isn't available) or printing the correct answer, which
will occur when GDB's internal TLS address resolution can be used.
I'm making this change prior to the commits which actually add
the GDB-internal TLS support in order to avoid tripping regression
testers.
---
gdb/testsuite/gdb.server/no-thread-db.exp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.server/no-thread-db.exp b/gdb/testsuite/gdb.server/no-thread-db.exp
index 656fad1a560..baad81b0f8e 100644
--- a/gdb/testsuite/gdb.server/no-thread-db.exp
+++ b/gdb/testsuite/gdb.server/no-thread-db.exp
@@ -57,6 +57,8 @@ gdb_breakpoint ${srcfile}:[gdb_get_line_number "after tls assignment"]
gdb_continue_to_breakpoint "after tls assignment"
# Printing a tls variable should fail gracefully without a libthread_db.
+# Alternately, the correct answer might be printed due GDB's internal
+# TLS support for some targets.
set re_exec "\[^\r\n\]*[file tail $binfile]"
gdb_test "print foo" \
- "Cannot find thread-local storage for Thread \[^,\]+, executable file $re_exec:\[\r\n\]+Remote target failed to process qGetTLSAddr request"
+ "= 1|(?:Cannot find thread-local storage for Thread \[^,\]+, executable file $re_exec:\[\r\n\]+Remote target failed to process qGetTLSAddr request)"
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 03/11] Track and fetch TLS module ids for MUSL and GLIBC
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 01/11] Don't attempt to find TLS address when target has no registers Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 02/11] Allow TLS access to work in gdb.server/no-thread-db.exp Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 04/11] Implement internal TLS address lookup for select Linux targets Kevin Buettner
` (8 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This commit adds, to solib-svr4.h and solib-svr4.c, functions
glibc_link_map_to_tls_module_id and musl_link_map_to_tls_module_id for
use with callers in a new file svr4-tls-tdep.c (which is not in this
commit). It adds a number of helper functions for implementing link
map to module id support.
It also renames existing function 'find_program_interpreter' to
'svr4_find_program_interpreter' and makes it visible to other source
files within GDB. It will be used in the libc sniffing code in
svr4-tls-tdep.c in a later commit in this series. The libc sniffer is
needed in order to know which link map to module id function to call
as the method for determining module ids differs between libc /
dynamic linker implementations. These details are discussed in
comments in the patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563
---
gdb/solib-svr4.c | 207 ++++++++++++++++++++++++++++++++++++++++++++++-
gdb/solib-svr4.h | 12 +++
2 files changed, 215 insertions(+), 4 deletions(-)
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 398123f7a52..99ba1bb8f6f 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -405,6 +405,9 @@ struct svr4_info
The special entry zero is reserved for a linear list to support
gdbstubs that do not support namespaces. */
std::map<CORE_ADDR, std::vector<svr4_so>> solib_lists;
+
+ bool glibc_tls_slots_inited = false;
+ std::vector<CORE_ADDR> glibc_tls_slots;
};
/* Per-program-space data key. */
@@ -586,10 +589,10 @@ read_program_header (int type, int *p_arch_size, CORE_ADDR *base_addr)
return buf;
}
+/* See solib-svr4.h. */
-/* Return program interpreter string. */
-static std::optional<gdb::byte_vector>
-find_program_interpreter (void)
+std::optional<gdb::byte_vector>
+svr4_find_program_interpreter ()
{
/* If we have a current exec_bfd, use its section table. */
if (current_program_space->exec_bfd ()
@@ -1516,6 +1519,198 @@ svr4_fetch_objfile_link_map (struct objfile *objfile)
return 0;
}
+/* Return true if bfd section BFD_SECT is a thread local section
+ (i.e. either named ".tdata" or ".tbss"), and false otherwise. */
+
+static bool
+is_thread_local_section (struct bfd_section *bfd_sect)
+{
+ return ((strcmp (bfd_sect->name, ".tdata") == 0
+ || strcmp (bfd_sect->name, ".tbss") == 0)
+ && bfd_sect->size != 0);
+}
+
+/* Return true if objfile OBJF contains a thread local section, and
+ false otherwise. */
+
+static bool
+has_thread_local_section (const objfile *objf)
+{
+ for (obj_section *objsec : objf->sections ())
+ if (is_thread_local_section (objsec->the_bfd_section))
+ return true;
+ return false;
+}
+
+/* Return true if solib SO contains a thread local section, and false
+ otherwise. */
+
+static bool
+has_thread_local_section (const solib &so)
+{
+ for (const target_section &p : so.sections)
+ if (is_thread_local_section (p.the_bfd_section))
+ return true;
+ return false;
+}
+
+/* For the MUSL C library, given link map address LM_ADDR, return the
+ corresponding TLS module id, or 0 if not found.
+
+ Background: Unlike the mechanism used by glibc (see below), the
+ scheme used by the MUSL C library is pretty simple. If the
+ executable contains TLS variables it gets module id 1. Otherwise,
+ the first shared object loaded which contains TLS variables is
+ assigned to module id 1. TLS-containing shared objects are then
+ assigned consecutive module ids, based on the order that they are
+ loaded. When unloaded via dlclose, module ids are reassigned as if
+ that module had never been loaded. */
+
+int
+musl_link_map_to_tls_module_id (CORE_ADDR lm_addr)
+{
+ /* When lm_addr is zero, the program is statically linked. Any TLS
+ variables will be in module id 1. */
+ if (lm_addr == 0)
+ return 1;
+
+ int mod_id = 0;
+ if (has_thread_local_section (current_program_space->symfile_object_file))
+ mod_id++;
+
+ struct svr4_info *info = get_svr4_info (current_program_space);
+
+ /* Cause svr4_current_sos() to be run if it hasn't been already. */
+ if (info->main_lm_addr == 0)
+ solib_add (NULL, 0, auto_solib_add);
+
+ /* Handle case where lm_addr corresponds to the main program.
+ Return value is either 0, when there are no TLS variables, or 1,
+ when there are. */
+ if (lm_addr == info->main_lm_addr)
+ return mod_id;
+
+ /* Iterate through the shared objects, possibly incrementing the
+ module id, and returning mod_id should a match be found. */
+ for (const solib &so : current_program_space->solibs ())
+ {
+ if (has_thread_local_section (so))
+ mod_id++;
+
+ auto *li = gdb::checked_static_cast<lm_info_svr4 *> (so.lm_info.get ());
+ if (li->lm_addr == lm_addr)
+ return mod_id;
+ }
+ return 0;
+}
+
+/* For GLIBC, given link map address LM_ADDR, return the corresponding TLS
+ module id, or 0 if not found. */
+
+int
+glibc_link_map_to_tls_module_id (CORE_ADDR lm_addr)
+{
+ /* When lm_addr is zero, the program is statically linked. Any TLS
+ variables will be in module id 1. */
+ if (lm_addr == 0)
+ return 1;
+
+ /* Look up lm_addr in the TLS slot data structure. */
+ struct svr4_info *info = get_svr4_info (current_program_space);
+ auto it = std::find (info->glibc_tls_slots.begin (),
+ info->glibc_tls_slots.end (),
+ lm_addr);
+ if (it == info->glibc_tls_slots.end ())
+ return 0;
+ else
+ return 1 + it - info->glibc_tls_slots.begin ();
+}
+
+/* Conditionally, based on whether the shared object, SO, contains TLS
+ variables, assign a link map address to a TLS module id slot. This
+ code is GLIBC-specific and may only work for specific GLIBC
+ versions. That said, it is known to work for (at least) GLIBC
+ versions 2.27 thru 2.40.
+
+ Background: In order to implement internal TLS address lookup
+ code, it is necessary to find the module id that has been
+ associated with a specific link map address. In GLIBC, the TLS
+ module id is stored in struct link_map, in the member
+ 'l_tls_modid'. While the first several members of struct link_map
+ are part of the SVR4 ABI, the offset to l_tls_modid definitely is
+ not. Therefore, since we don't know the offset to l_tls_modid, we
+ cannot simply look it up - which is a shame, because things would
+ be so much more easy and obviously accurate, if we could access
+ l_tls_modid.
+
+ GLIBC has a concept of TLS module id slots. These slots are
+ allocated consecutively as shared objects containing TLS variables
+ are loaded. When unloaded (e.g. via dlclose()), the corresponding
+ slot is marked as unused, but may be used again when later loading
+ a shared object.
+
+ The functions tls_maybe_fill_slot and tls_maybe_erase_slot are
+ associated with the observers 'solib_loaded' and 'solib_unloaded'.
+ They (attempt to) track use of TLS module id slots in the same way
+ that GLIBC does, which will hopefully provide an accurate module id
+ when asked to provide it via glibc_link_map_to_tls_module_id(),
+ above. */
+
+static void
+tls_maybe_fill_slot (solib &so)
+{
+ struct svr4_info *info = get_svr4_info (current_program_space);
+ if (!info->glibc_tls_slots_inited)
+ {
+ /* Cause svr4_current_sos() to be run if it hasn't been already. */
+ if (info->main_lm_addr == 0)
+ svr4_current_sos_direct (info);
+
+ /* Quit early when main_lm_addr is still 0. */
+ if (info->main_lm_addr == 0)
+ return;
+
+ /* Also quit early when symfile_object_file is not yet known. */
+ if (current_program_space->symfile_object_file == nullptr)
+ return;
+
+ if (has_thread_local_section (current_program_space->symfile_object_file))
+ info->glibc_tls_slots.push_back (info->main_lm_addr);
+ info->glibc_tls_slots_inited = true;
+ }
+
+ if (has_thread_local_section (so))
+ {
+ auto it = std::find (info->glibc_tls_slots.begin (),
+ info->glibc_tls_slots.end (),
+ 0);
+ auto *li = gdb::checked_static_cast<lm_info_svr4 *> (so.lm_info.get ());
+ if (it == info->glibc_tls_slots.end ())
+ info->glibc_tls_slots.push_back (li->lm_addr);
+ else
+ *it = li->lm_addr;
+ }
+}
+
+/* Remove a link map address from the TLS module slot data structure.
+ As noted above, this code is GLIBC-specific. */
+
+static void
+tls_maybe_erase_slot (program_space *pspace, const solib &so,
+ bool still_in_use, bool silent)
+{
+ if (still_in_use)
+ return;
+
+ struct svr4_info *info = get_svr4_info (pspace);
+ auto *li = gdb::checked_static_cast<lm_info_svr4 *> (so.lm_info.get ());
+ auto it = std::find (info->glibc_tls_slots.begin (),
+ info->glibc_tls_slots.end (),
+ li->lm_addr);
+ if (it != info->glibc_tls_slots.end ())
+ *it = 0;
+}
+
/* On some systems, the only way to recognize the link map entry for
the main executable file is by looking at its name. Return
non-zero iff SONAME matches one of the known main executable names. */
@@ -2307,7 +2502,7 @@ enable_break (struct svr4_info *info, int from_tty)
/* Find the program interpreter; if not found, warn the user and drop
into the old breakpoint at symbol code. */
std::optional<gdb::byte_vector> interp_name_holder
- = find_program_interpreter ();
+ = svr4_find_program_interpreter ();
if (interp_name_holder)
{
const char *interp_name = (const char *) interp_name_holder->data ();
@@ -3483,4 +3678,8 @@ _initialize_svr4_solib ()
{
gdb::observers::free_objfile.attach (svr4_free_objfile_observer,
"solib-svr4");
+
+ /* Set up observers for tracking GLIBC TLS module id slots. */
+ gdb::observers::solib_loaded.attach (tls_maybe_fill_slot, "solib-svr4");
+ gdb::observers::solib_unloaded.attach (tls_maybe_erase_slot, "solib-svr4");
}
diff --git a/gdb/solib-svr4.h b/gdb/solib-svr4.h
index 37cdaff4882..618eac52d72 100644
--- a/gdb/solib-svr4.h
+++ b/gdb/solib-svr4.h
@@ -112,4 +112,16 @@ extern struct link_map_offsets *svr4_lp64_fetch_link_map_offsets (void);
SVR4 run time loader. */
int svr4_in_dynsym_resolve_code (CORE_ADDR pc);
+/* For the MUSL C library, given link map address LM_ADDR, return the
+ corresponding TLS module id, or 0 if not found. */
+int musl_link_map_to_tls_module_id (CORE_ADDR lm_addr);
+
+/* For GLIBC, given link map address LM_ADDR, return the corresponding TLS
+ module id, or 0 if not found. */
+int glibc_link_map_to_tls_module_id (CORE_ADDR lm_addr);
+
+/* Return program interpreter string. */
+
+std::optional<gdb::byte_vector> svr4_find_program_interpreter ();
+
#endif /* GDB_SOLIB_SVR4_H */
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 04/11] Implement internal TLS address lookup for select Linux targets
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (2 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 03/11] Track and fetch TLS module ids for MUSL and GLIBC Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 05/11] Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x Kevin Buettner
` (7 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This commit adds non-architecture-specific support for internal TLS
address lookup for targets which register their support with the new
file svr4-tls-tdep.c. By "internal", I mean support which does not
rely on libthread_db. Knowledge of how to traverse TLS data
structures is contained in this commit along with the next commit
containing architecture specific knowledge regarding TLS offsets,
registers, and such.
The new function 'svr4_tls_get_thread_local_address' is a gdbarch method.
It should be passed as an argument to
set_gdbarch_get_thread_local_address in architecture specific
<arch>-linux-tdep.c files which wish to offer internal TLS support.
The architecture specific tdep files need to define a get_tls_dtv_addr
method - as the name suggests, it needs to return the address of the
DTV (dynamic thread vector) via architecture specific means. This
usually entails fetching the thread pointer via a register or registers
assigned to this purpose, and then using that value to locate the
address of the DTV from within the TCB (thread control block).
Additionally, some architectures also need to provide a DTP offset,
which is used by the MUSL C library to adjust the value obtained
from a DTV entry to that of the start of the TLS block for a particular
thread. This is provided, when necessary, by a get_tls_dtp_offset
method.
Both methods, get_tls_dtv_addr and get_tls_dtp_offset, are registered
with data structures maintained by linux-tdep.c via the new function
svr4_tls_register_tls_methods(). Thus, for example, on RISC-V,
riscv_linux_init_abi() will make the following two calls, the first
for registering the internal get_thread_local_address gdbarch method
and the second for registering riscv-specific methods for obtaining
the DTV address and DTP offset:
set_gdbarch_get_thread_local_address (gdbarch,
svr4_tls_get_thread_local_address);
svr4_tls_register_tls_methods (info, gdbarch, riscv_linux_get_tls_dtv_addr,
riscv_linux_get_tls_dtp_offset);
Internal TLS support is provided for two C libraries, GLIBC, and MUSL.
Details for accessing the various TLS data structures differ between
these libraries. As a consequence, linux-tdep.h defines a new enum,
svr4_tls_libc, with values svr4_tls_libc_unknown, svr4_tls_libc_musl,
and svr4_tls_libc_glibc. A new static function libc_tls_sniffer uses
heuristics to (try to) decide whether a program was linked against
GLIBC or MUSL. Working out what the heuristics should be, especially
for statically linked binaries, turned out to be harder than I thought
it would be.
A new maintenance setting, force-internal-tls-address-lookup, has been
added, which, when set to 'on', will (as the name suggests) force the
internal TLS lookup mechanisms to be used. Otherwise, if thread_db
support is available (via the thread stratum), that will be preferred
since it should be more accurate. I expect that this setting will be
mostly used by test cases in the GDB test suite. The new test cases
that are part of this series all use it, with iterations using both
'on' and 'off' for all of the tests therein.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563
---
gdb/Makefile.in | 3 +
gdb/linux-tdep.c | 1 +
gdb/svr4-tls-tdep.c | 256 ++++++++++++++++++++++++++++++++++++++++++++
gdb/svr4-tls-tdep.h | 59 ++++++++++
4 files changed, 319 insertions(+)
create mode 100644 gdb/svr4-tls-tdep.c
create mode 100644 gdb/svr4-tls-tdep.h
diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 0c4102d2565..8d333d573d0 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -896,6 +896,7 @@ ALL_TARGET_OBS = \
sparc-ravenscar-thread.o \
sparc-sol2-tdep.o \
sparc-tdep.o \
+ svr4-tls-tdep.o \
symfile-mem.o \
tic6x-linux-tdep.o \
tic6x-tdep.o \
@@ -1520,6 +1521,7 @@ HFILES_NO_SRCDIR = \
stabsread.h \
stack.h \
stap-probe.h \
+ svr4-tls-tdep.h \
symfile.h \
symtab.h \
target.h \
@@ -1883,6 +1885,7 @@ ALLDEPFILES = \
sparc64-obsd-tdep.c \
sparc64-sol2-tdep.c \
sparc64-tdep.c \
+ svr4-tls-tdep.c \
tilegx-linux-nat.c \
tilegx-linux-tdep.c \
tilegx-tdep.c \
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 852fea7e3d9..c3bd5bfe527 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -3137,6 +3137,7 @@ VM_DONTDUMP flag (\"dd\" in /proc/PID/smaps) when generating the corefile. For\
more information about this file, refer to the manpage of proc(5) and core(5)."),
NULL, show_dump_excluded_mappings,
&setlist, &showlist);
+
}
/* Fetch (and possibly build) an appropriate `link_map_offsets' for
diff --git a/gdb/svr4-tls-tdep.c b/gdb/svr4-tls-tdep.c
new file mode 100644
index 00000000000..619fec038cd
--- /dev/null
+++ b/gdb/svr4-tls-tdep.c
@@ -0,0 +1,256 @@
+/* Target-dependent code for GNU/Linux, architecture independent.
+
+ Copyright (C) 2009-2024 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "svr4-tls-tdep.h"
+#include "solib-svr4.h"
+#include "inferior.h"
+#include "objfiles.h"
+#include "cli/cli-cmds.h"
+#include <optional>
+
+struct svr4_tls_gdbarch_data
+{
+ /* Method for looking up TLS DTV. */
+ get_tls_dtv_addr_ftype *get_tls_dtv_addr = nullptr;
+
+ /* Method for looking up the TLS DTP offset. */
+ get_tls_dtp_offset_ftype *get_tls_dtp_offset = nullptr;
+
+ /* Cached libc value for TLS lookup purposes. */
+ enum svr4_tls_libc libc = svr4_tls_libc_unknown;
+};
+
+static const registry<gdbarch>::key<svr4_tls_gdbarch_data>
+ svr4_tls_gdbarch_data_handle;
+
+static struct svr4_tls_gdbarch_data *
+get_svr4_tls_gdbarch_data (struct gdbarch *gdbarch)
+{
+ struct svr4_tls_gdbarch_data *result = svr4_tls_gdbarch_data_handle.get (gdbarch);
+ if (result == nullptr)
+ result = svr4_tls_gdbarch_data_handle.emplace (gdbarch);
+ return result;
+}
+
+/* When true, force internal TLS address lookup instead of lookup via
+ the thread stratum. */
+
+static bool force_internal_tls_address_lookup = false;
+
+/* For TLS lookup purposes, use heuristics to decide whether program
+ was linked against MUSL or GLIBC. */
+
+static enum svr4_tls_libc
+libc_tls_sniffer (struct gdbarch *gdbarch)
+{
+ /* Check for cached libc value. */
+ svr4_tls_gdbarch_data *gdbarch_data = get_svr4_tls_gdbarch_data (gdbarch);
+ if (gdbarch_data->libc != svr4_tls_libc_unknown)
+ return gdbarch_data->libc;
+
+ svr4_tls_libc libc = svr4_tls_libc_unknown;
+
+ /* Fetch the program interpreter. */
+ std::optional<gdb::byte_vector> interp_name_holder
+ = svr4_find_program_interpreter ();
+ if (interp_name_holder)
+ {
+ /* A dynamically linked program linked against MUSL will have a
+ "ld-musl-" in its interpreter name. (Two examples of MUSL
+ interpreter names are "/lib/ld-musl-x86_64.so.1" and
+ "lib/ld-musl-aarch64.so.1".) If it's not found, assume GLIBC. */
+ const char *interp_name = (const char *) interp_name_holder->data ();
+ if (strstr (interp_name, "/ld-musl-") != nullptr)
+ libc = svr4_tls_libc_musl;
+ else
+ libc = svr4_tls_libc_glibc;
+ gdbarch_data->libc = libc;
+ return libc;
+ }
+
+ /* If there is no interpreter name, it's statically linked. For
+ programs with TLS data, a program statically linked against MUSL
+ will have the symbols 'main_tls' and 'builtin_tls'. If both of
+ these are present, assume that it was statically linked against
+ MUSL, otherwise assume GLIBC. */
+ if (lookup_minimal_symbol (current_program_space, "main_tls").minsym
+ != nullptr
+ && lookup_minimal_symbol (current_program_space, "builtin_tls").minsym
+ != nullptr)
+ libc = svr4_tls_libc_musl;
+ else
+ libc = svr4_tls_libc_glibc;
+ gdbarch_data->libc = libc;
+ return libc;
+}
+
+/* Implement gdbarch method, get_thread_local_address, for architectures
+ which provide a method for determining the DTV and possibly the DTP
+ offset. */
+
+CORE_ADDR
+svr4_tls_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid,
+ CORE_ADDR lm_addr, CORE_ADDR offset)
+{
+ svr4_tls_gdbarch_data *gdbarch_data = get_svr4_tls_gdbarch_data (gdbarch);
+
+ /* Use the target's get_thread_local_address method when:
+
+ - No method has been provided for finding the TLS DTV.
+
+ or
+
+ - The thread stratum has been pushed (at some point) onto the
+ target stack, except when 'force_internal_tls_address_lookup'
+ has been set.
+
+ The idea here is to prefer use of of the target's thread_stratum
+ method since it should be more accurate. */
+ if (gdbarch_data->get_tls_dtv_addr == nullptr
+ || (find_target_at (thread_stratum) != nullptr
+ && !force_internal_tls_address_lookup))
+ {
+ struct target_ops *target = current_inferior ()->top_target ();
+ return target->get_thread_local_address (ptid, lm_addr, offset);
+ }
+ else
+ {
+ /* Details, found below, regarding TLS layout is for the GNU C
+ library (glibc) and the MUSL C library (musl), circa 2024.
+ While some of this layout is defined by the TLS ABI, some of
+ it, such as how/where to find the DTV pointer in the TCB, is
+ not. A good source of ABI info for some architectures can be
+ found in "ELF Handling For Thread-Local Storage" by Ulrich
+ Drepper. That document is worth consulting even for
+ architectures not described there, since the general approach
+ and terminology is used regardless.
+
+ Some architectures, such as aarch64, are not described in
+ that document, so some details had to ferreted out using the
+ glibc source code. Likewise, the MUSL source code was
+ consulted for details which differ from GLIBC. */
+ enum svr4_tls_libc libc = libc_tls_sniffer (gdbarch);
+ int mod_id;
+ if (libc == svr4_tls_libc_glibc)
+ mod_id = glibc_link_map_to_tls_module_id (lm_addr);
+ else /* Assume MUSL. */
+ mod_id = musl_link_map_to_tls_module_id (lm_addr);
+ if (mod_id == 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to determine TLS module id"));
+
+ /* Use the architecture specific DTV fetcher to obtain the DTV. */
+ CORE_ADDR dtv_addr = gdbarch_data->get_tls_dtv_addr (gdbarch, ptid, libc);
+
+ /* In GLIBC, The DTV (dynamic thread vector) is an array of
+ structs consisting of two fields, the first of which is a
+ pointer to the TLS block of interest. (The second field is a
+ pointer that assists with memory management, but that's not
+ of interest here.) Also, the 0th entry is the generation
+ number, but although it's a single scalar, the 0th entry is
+ padded to be the same size as all the rest. Thus each
+ element of the DTV array is two pointers in size.
+
+ In MUSL, the DTV is simply an array of pointers. The 0th
+ entry is still the generation number, but contains no padding
+ aside from that which is needed to make it pointer sized. */
+ int m; /* Multiplier, for size of DTV entry. */
+ switch (libc)
+ {
+ case svr4_tls_libc_glibc:
+ m = 2;
+ break;
+ default:
+ m = 1;
+ break;
+ }
+
+ /* Obtain TLS block address. Module ids start at 1, so there's
+ no need to adjust it to skip over the 0th entry of the DTV,
+ which is the generation number. */
+ CORE_ADDR dtv_elem_addr
+ = dtv_addr + mod_id * m * (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_elem_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch TLS block address"));
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR tls_block_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr,
+ buf.data ());
+
+ /* When the TLS block addr is 0 or -1, this usually indicates that
+ the TLS storage hasn't been allocated yet. (In GLIBC, some
+ architectures use 0 while others use -1.) */
+ if (tls_block_addr == 0 || tls_block_addr == (CORE_ADDR) -1)
+ throw_error (TLS_NOT_ALLOCATED_YET_ERROR, _("TLS not allocated yet"));
+
+ /* MUSL (and perhaps other C libraries, though not GLIBC) have
+ TLS implementations for some architectures which, for some
+ reason, have DTV entries which must be negatively offset by
+ DTP_OFFSET in order to obtain the TLS block address.
+ DTP_OFFSET is a constant in the MUSL sources - these offsets,
+ when they're non-zero, seem to be either 0x800 or 0x8000,
+ and are present for riscv[32/64], powerpc[32/64], m68k, and
+ mips.
+
+ Use the architecture specific get_tls_dtp_offset method, if
+ present, to obtain this offset. */
+ ULONGEST dtp_offset
+ = gdbarch_data->get_tls_dtp_offset == nullptr
+ ? 0
+ : gdbarch_data->get_tls_dtp_offset (gdbarch, ptid, libc);
+
+ return tls_block_addr - dtp_offset + offset;
+ }
+}
+
+/* See svr4-tls-tdep.h. */
+
+void
+svr4_tls_register_tls_methods (struct gdbarch_info info, struct gdbarch *gdbarch,
+ get_tls_dtv_addr_ftype *get_tls_dtv_addr,
+ get_tls_dtp_offset_ftype *get_tls_dtp_offset)
+{
+ gdb_assert (get_tls_dtv_addr != nullptr);
+
+ svr4_tls_gdbarch_data *gdbarch_data = get_svr4_tls_gdbarch_data (gdbarch);
+ gdbarch_data->get_tls_dtv_addr = get_tls_dtv_addr;
+ gdbarch_data->get_tls_dtp_offset = get_tls_dtp_offset;
+}
+
+void _initialize_svr4_tls_tdep ();
+void
+_initialize_svr4_tls_tdep ()
+{
+ add_setshow_boolean_cmd ("force-internal-tls-address-lookup", class_obscure,
+ &force_internal_tls_address_lookup, _("\
+Set to force internal TLS address lookup."), _("\
+Show whether GDB is forced to use internal TLS address lookup."), _("\
+When resolving addresses for TLS (Thread Local Storage) variables,\n\
+GDB will attempt to use facilities provided by the thread library (i.e.\n\
+libthread_db). If those facilities aren't available, GDB will fall\n\
+back to using some internal (to GDB), but possibly less accurate\n\
+mechanisms to resolve the addresses for TLS variables. When this flag\n\
+is set, GDB will force use of the fall-back TLS resolution mechanisms.\n\
+This flag is used by some GDB tests to ensure that the internal fallback\n\
+code is exercised and working as expected. The default is to not force\n\
+the internal fall-back mechanisms to be used."),
+ NULL, NULL,
+ &maintenance_set_cmdlist,
+ &maintenance_show_cmdlist);
+}
diff --git a/gdb/svr4-tls-tdep.h b/gdb/svr4-tls-tdep.h
new file mode 100644
index 00000000000..73efc024c9b
--- /dev/null
+++ b/gdb/svr4-tls-tdep.h
@@ -0,0 +1,59 @@
+/* Target-dependent code for GNU/Linux, architecture independent.
+
+ Copyright (C) 2025 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#ifndef GDB_SVR4_TLS_TDEP_H
+#define GDB_SVR4_TLS_TDEP_H
+
+/* C library variants for TLS lookup. */
+
+enum svr4_tls_libc
+{
+ svr4_tls_libc_unknown,
+ svr4_tls_libc_musl,
+ svr4_tls_libc_glibc
+};
+
+/* Function type for "get_tls_dtv_addr" method. */
+
+typedef CORE_ADDR (get_tls_dtv_addr_ftype) (struct gdbarch *gdbarch,
+ ptid_t ptid,
+ enum svr4_tls_libc libc);
+
+/* Function type for "get_tls_dtp_offset" method. */
+
+typedef CORE_ADDR (get_tls_dtp_offset_ftype) (struct gdbarch *gdbarch,
+ ptid_t ptid,
+ enum svr4_tls_libc libc);
+
+/* Register architecture specific methods for fetching the TLS DTV
+ and TLS DTP, used by linux_get_thread_local_address. */
+
+extern void svr4_tls_register_tls_methods
+ (struct gdbarch_info info, struct gdbarch *gdbarch,
+ get_tls_dtv_addr_ftype *get_tls_dtv_addr,
+ get_tls_dtp_offset_ftype *get_tls_dtp_offset = nullptr);
+
+/* Used as a gdbarch method for get_thread_local_address when the tdep
+ file also defines a suitable method for obtaining the TLS DTV.
+ See linux_init_abi(), above. */
+CORE_ADDR
+svr4_tls_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid,
+ CORE_ADDR lm_addr, CORE_ADDR offset);
+
+#endif /* GDB_SVR4_TLS_TDEP_H */
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 05/11] Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (3 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 04/11] Implement internal TLS address lookup for select Linux targets Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 06/11] Internal, but disabled, TLS support for i386 Kevin Buettner
` (6 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner, Luis Machado
For each architecture, aarch64, x86_64, riscv, ppc64, and s390x,
this commit defines a suitable 'get_tls_dtv_addr' method and,
when necessary, a 'get_tls_dtp_offset' method.
It also registers svr4_tls_get_thread_local_address, defined in
svr4-tls-tdep.c (in an earlier commit), as the
get_thread_local_address gdbarch method. It also registers its
architecture specific code using svr4_tls_register_tls_methods().
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563
Reviewed-By: Luis Machado <luis.machado@arm.com>
---
gdb/aarch64-linux-tdep.c | 56 ++++++++++++++++++++++++++++
gdb/amd64-linux-tdep.c | 38 +++++++++++++++++++
gdb/configure.tgt | 11 +++---
gdb/ppc-linux-tdep.c | 63 ++++++++++++++++++++++++++++++++
gdb/riscv-linux-tdep.c | 79 ++++++++++++++++++++++++++++++++++++++++
gdb/s390-linux-tdep.c | 44 ++++++++++++++++++++++
6 files changed, 286 insertions(+), 5 deletions(-)
diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c
index c8256997c97..db3a557e622 100644
--- a/gdb/aarch64-linux-tdep.c
+++ b/gdb/aarch64-linux-tdep.c
@@ -24,6 +24,7 @@
#include "gdbarch.h"
#include "glibc-tdep.h"
#include "linux-tdep.h"
+#include "svr4-tls-tdep.h"
#include "aarch64-tdep.h"
#include "aarch64-linux-tdep.h"
#include "osabi.h"
@@ -35,6 +36,7 @@
#include "target/target.h"
#include "expop.h"
#include "auxv.h"
+#include "inferior.h"
#include "regcache.h"
#include "regset.h"
@@ -2701,6 +2703,57 @@ aarch64_use_target_description_from_corefile_notes (gdbarch *gdbarch,
return true;
}
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+aarch64_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ svr4_tls_libc libc)
+{
+ /* On aarch64, the thread pointer is found in the TPIDR register.
+ Note that this is the first register in the TLS feature - see
+ features/aarch64-tls.c - and it will always be present. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
+ target_fetch_registers (regcache, tdep->tls_regnum_base);
+ ULONGEST thr_ptr;
+ if (regcache->cooked_read (tdep->tls_regnum_base, &thr_ptr) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+
+ CORE_ADDR dtv_ptr_addr;
+ switch (libc)
+ {
+ case svr4_tls_libc_musl:
+ /* MUSL: The DTV pointer is found at the very end of the pthread
+ struct which is located *before* the thread pointer. I.e.
+ the thread pointer will be just beyond the end of the struct,
+ so the address of the DTV pointer is found one pointer-size
+ before the thread pointer. */
+ dtv_ptr_addr = thr_ptr - (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ break;
+ case svr4_tls_libc_glibc:
+ /* GLIBC: The thread pointer (tpidr) points at the TCB (thread control
+ block). On aarch64, this struct (tcbhead_t) is defined to
+ contain two pointers. The first is a pointer to the DTV and
+ the second is a pointer to private data. So the DTV pointer
+ address is the same as the thread pointer. */
+ dtv_ptr_addr = thr_ptr;
+ break;
+ default:
+ throw_error (TLS_GENERIC_ERROR, _("Unknown aarch64 C library"));
+ break;
+ }
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+
static void
aarch64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
{
@@ -2722,6 +2775,9 @@ aarch64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, aarch64_linux_get_tls_dtv_addr);
/* Shared library handling. */
set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
index a7868c35cd5..cd690326c30 100644
--- a/gdb/amd64-linux-tdep.c
+++ b/gdb/amd64-linux-tdep.c
@@ -33,7 +33,9 @@
#include "amd64-linux-tdep.h"
#include "i386-linux-tdep.h"
#include "linux-tdep.h"
+#include "svr4-tls-tdep.h"
#include "gdbsupport/x86-xstate.h"
+#include "inferior.h"
#include "amd64-tdep.h"
#include "solib-svr4.h"
@@ -1832,6 +1834,39 @@ amd64_linux_remove_non_address_bits_watchpoint (gdbarch *gdbarch,
return (addr & amd64_linux_lam_untag_mask ());
}
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+amd64_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ enum svr4_tls_libc libc)
+{
+ /* On x86-64, the thread pointer is found in the fsbase register. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ target_fetch_registers (regcache, AMD64_FSBASE_REGNUM);
+ ULONGEST fsbase;
+ if (regcache->cooked_read (AMD64_FSBASE_REGNUM, &fsbase) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+
+ /* The thread pointer (fsbase) points at the TCB (thread control
+ block). The first two members of this struct are both pointers,
+ where the first will be a pointer to the TCB (i.e. it points at
+ itself) and the second will be a pointer to the DTV (dynamic
+ thread vector). There are many other fields too, but the one
+ we care about here is the DTV pointer. Compute the address
+ of the DTV pointer, fetch it, and convert it to an address. */
+ CORE_ADDR dtv_ptr_addr = fsbase + gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+
static void
amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbarch,
int num_disp_step_buffers)
@@ -1862,6 +1897,9 @@ amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbarch,
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, amd64_linux_get_tls_dtv_addr);
/* GNU/Linux uses SVR4-style shared libraries. */
set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
diff --git a/gdb/configure.tgt b/gdb/configure.tgt
index 18a15c032c3..d8d0c5f4aeb 100644
--- a/gdb/configure.tgt
+++ b/gdb/configure.tgt
@@ -150,7 +150,7 @@ aarch64*-*-linux*)
arch/aarch64-scalable-linux.o \
arch/arm.o arch/arm-linux.o arch/arm-get-next-pcs.o \
arm-tdep.o arm-linux-tdep.o \
- glibc-tdep.o linux-tdep.o solib-svr4.o \
+ glibc-tdep.o linux-tdep.o solib-svr4.o svr4-tls-tdep.o \
symfile-mem.o linux-record.o"
;;
@@ -503,7 +503,7 @@ powerpc-*-aix* | rs6000-*-* | powerpc64-*-aix*)
powerpc*-*-linux*)
# Target: PowerPC running Linux
gdb_target_obs="rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o \
- ppc64-tdep.o solib-svr4.o \
+ ppc64-tdep.o solib-svr4.o svr4-tls-tdep.o \
glibc-tdep.o symfile-mem.o linux-tdep.o \
ravenscar-thread.o ppc-ravenscar-thread.o \
linux-record.o \
@@ -524,7 +524,8 @@ powerpc*-*-*)
s390*-*-linux*)
# Target: S390 running Linux
gdb_target_obs="s390-linux-tdep.o s390-tdep.o solib-svr4.o \
- linux-tdep.o linux-record.o symfile-mem.o"
+ linux-tdep.o linux-record.o symfile-mem.o \
+ svr4-tls-tdep.o"
;;
riscv*-*-freebsd*)
@@ -534,7 +535,7 @@ riscv*-*-freebsd*)
riscv*-*-linux*)
# Target: Linux/RISC-V
- gdb_target_obs="riscv-linux-tdep.o glibc-tdep.o \
+ gdb_target_obs="riscv-linux-tdep.o glibc-tdep.o svr4-tls-tdep.o \
linux-tdep.o solib-svr4.o symfile-mem.o linux-record.o"
;;
@@ -705,7 +706,7 @@ x86_64-*-elf*)
x86_64-*-linux*)
# Target: GNU/Linux x86-64
gdb_target_obs="amd64-linux-tdep.o ${i386_tobjs} \
- i386-linux-tdep.o glibc-tdep.o \
+ i386-linux-tdep.o glibc-tdep.o svr4-tls-tdep.o \
solib-svr4.o symfile-mem.o linux-tdep.o linux-record.o \
arch/i386-linux-tdesc.o arch/amd64-linux-tdesc.o \
arch/x86-linux-tdesc-features.o"
diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c
index a9f43c43861..590c4b2a96c 100644
--- a/gdb/ppc-linux-tdep.c
+++ b/gdb/ppc-linux-tdep.c
@@ -49,6 +49,7 @@
#include "arch-utils.h"
#include "xml-syscall.h"
#include "linux-tdep.h"
+#include "svr4-tls-tdep.h"
#include "linux-record.h"
#include "record-full.h"
#include "infrun.h"
@@ -2071,6 +2072,63 @@ ppc64_linux_gcc_target_options (struct gdbarch *gdbarch)
return "";
}
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+ppc64_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ enum svr4_tls_libc libc)
+{
+ /* On ppc64, the thread pointer is found in r13. Fetch this
+ register. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ int thread_pointer_regnum = PPC_R0_REGNUM + 13;
+ target_fetch_registers (regcache, thread_pointer_regnum);
+ ULONGEST thr_ptr;
+ if (regcache->cooked_read (thread_pointer_regnum, &thr_ptr) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+
+ /* The thread pointer (r13) is an address that is 0x7000 ahead of
+ the *end* of the TCB (thread control block). The field
+ holding the DTV address is at the very end of the TCB.
+ Therefore, the DTV pointer address can be found by
+ subtracting (0x7000+8) from the thread pointer. Compute the
+ address of the DTV pointer, fetch it, and convert it to an
+ address. */
+ CORE_ADDR dtv_ptr_addr = thr_ptr - 0x7000 - 8;
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+
+/* For internal TLS lookup, return the DTP offset, which is the offset
+ to subtract from a DTV entry, in order to obtain the address of the
+ TLS block. */
+
+static ULONGEST
+ppc_linux_get_tls_dtp_offset (struct gdbarch *gdbarch, ptid_t ptid,
+ svr4_tls_libc libc)
+{
+ if (libc == svr4_tls_libc_musl)
+ {
+ /* This value is DTP_OFFSET, which represents the value to
+ subtract from the DTV entry. For PPC, it can be found in
+ MUSL's arch/powerpc64/pthread_arch.h and
+ arch/powerpc32/pthread_arch.h. (Both values are the same.)
+ It represents the value to subtract from the DTV entry, once
+ it has been fetched from the DTV array. */
+ return 0x8000;
+ }
+ else
+ return 0;
+}
+
static displaced_step_prepare_status
ppc_linux_displaced_step_prepare (gdbarch *arch, thread_info *thread,
CORE_ADDR &displaced_pc)
@@ -2284,6 +2342,11 @@ ppc_linux_init_abi (struct gdbarch_info info,
set_gdbarch_gnu_triplet_regexp (gdbarch, ppc64_gnu_triplet_regexp);
/* Set GCC target options. */
set_gdbarch_gcc_target_options (gdbarch, ppc64_linux_gcc_target_options);
+ /* Internal thread local address support. */
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, ppc64_linux_get_tls_dtv_addr,
+ ppc_linux_get_tls_dtp_offset);
}
set_gdbarch_core_read_description (gdbarch, ppc_linux_core_read_description);
diff --git a/gdb/riscv-linux-tdep.c b/gdb/riscv-linux-tdep.c
index ff478cf4c28..21345fb25c3 100644
--- a/gdb/riscv-linux-tdep.c
+++ b/gdb/riscv-linux-tdep.c
@@ -20,11 +20,13 @@
#include "osabi.h"
#include "glibc-tdep.h"
#include "linux-tdep.h"
+#include "svr4-tls-tdep.h"
#include "solib-svr4.h"
#include "regset.h"
#include "tramp-frame.h"
#include "trad-frame.h"
#include "gdbarch.h"
+#include "inferior.h"
/* The following value is derived from __NR_rt_sigreturn in
<include/uapi/asm-generic/unistd.h> from the Linux source tree. */
@@ -173,6 +175,79 @@ riscv_linux_syscall_next_pc (const frame_info_ptr &frame)
return pc + 4 /* Length of the ECALL insn. */;
}
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+riscv_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ svr4_tls_libc libc)
+{
+ /* On RISC-V, the thread pointer is found in TP. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ int thread_pointer_regnum = RISCV_TP_REGNUM;
+ target_fetch_registers (regcache, thread_pointer_regnum);
+ ULONGEST thr_ptr;
+ if (regcache->cooked_read (thread_pointer_regnum, &thr_ptr) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+
+ CORE_ADDR dtv_ptr_addr;
+ switch (libc)
+ {
+ case svr4_tls_libc_musl:
+ /* MUSL: The DTV pointer is found at the very end of the pthread
+ struct which is located *before* the thread pointer. I.e.
+ the thread pointer will be just beyond the end of the struct,
+ so the address of the DTV pointer is found one pointer-size
+ before the thread pointer. */
+ dtv_ptr_addr
+ = thr_ptr - (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ break;
+ case svr4_tls_libc_glibc:
+ /* GLIBC: The thread pointer (TP) points just beyond the end of
+ the TCB (thread control block). On RISC-V, this struct
+ (tcbhead_t) is defined to contain two pointers. The first is
+ a pointer to the DTV and the second is a pointer to private
+ data. So the DTV pointer address is 16 bytes (i.e. the size of
+ two pointers) before thread pointer. */
+
+ dtv_ptr_addr
+ = thr_ptr - 2 * (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ break;
+ default:
+ throw_error (TLS_GENERIC_ERROR, _("Unknown RISC-V C library"));
+ break;
+ }
+
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+
+/* For internal TLS lookup, return the DTP offset, which is the offset
+ to subtract from a DTV entry, in order to obtain the address of the
+ TLS block. */
+
+static ULONGEST
+riscv_linux_get_tls_dtp_offset (struct gdbarch *gdbarch, ptid_t ptid,
+ svr4_tls_libc libc)
+{
+ if (libc == svr4_tls_libc_musl)
+ {
+ /* This value is DTP_OFFSET in MUSL's arch/riscv64/pthread_arch.h.
+ It represents the value to subtract from the DTV entry, once
+ it has been loaded. */
+ return 0x800;
+ }
+ else
+ return 0;
+}
+
/* Initialize RISC-V Linux ABI info. */
static void
@@ -198,6 +273,10 @@ riscv_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, riscv_linux_get_tls_dtv_addr,
+ riscv_linux_get_tls_dtp_offset);
set_gdbarch_iterate_over_regset_sections
(gdbarch, riscv_linux_iterate_over_regset_sections);
diff --git a/gdb/s390-linux-tdep.c b/gdb/s390-linux-tdep.c
index 96d6d446219..aa444a8dc00 100644
--- a/gdb/s390-linux-tdep.c
+++ b/gdb/s390-linux-tdep.c
@@ -29,6 +29,7 @@
#include "gdbcore.h"
#include "linux-record.h"
#include "linux-tdep.h"
+#include "svr4-tls-tdep.h"
#include "objfiles.h"
#include "osabi.h"
#include "regcache.h"
@@ -40,6 +41,7 @@
#include "target.h"
#include "trad-frame.h"
#include "xml-syscall.h"
+#include "inferior.h"
#include "features/s390-linux32v1.c"
#include "features/s390-linux32v2.c"
@@ -1124,6 +1126,45 @@ s390_init_linux_record_tdep (struct linux_record_tdep *record_tdep,
record_tdep->ioctl_FIOQSIZE = 0x545e;
}
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+s390_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ enum svr4_tls_libc libc)
+{
+ /* On S390, the thread pointer is found in two registers A0 and A1
+ (or, using gdb naming, acr0 and acr1) A0 contains the top 32
+ bits of the address and A1 contains the bottom 32 bits. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ target_fetch_registers (regcache, S390_A0_REGNUM);
+ target_fetch_registers (regcache, S390_A1_REGNUM);
+ ULONGEST thr_ptr_lo, thr_ptr_hi, thr_ptr;
+ if (regcache->cooked_read (S390_A0_REGNUM, &thr_ptr_hi) != REG_VALID
+ || regcache->cooked_read (S390_A1_REGNUM, &thr_ptr_lo) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+ thr_ptr = (thr_ptr_hi << 32) + thr_ptr_lo;
+
+ /* The thread pointer points at the TCB (thread control block). The
+ first two members of this struct are both pointers, where the
+ first will be a pointer to the TCB (i.e. it points at itself)
+ and the second will be a pointer to the DTV (dynamic thread
+ vector). There are many other fields too, but the one we care
+ about here is the DTV pointer. Compute the address of the DTV
+ pointer, fetch it, and convert it to an address. */
+ CORE_ADDR dtv_ptr_addr
+ = thr_ptr + gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+
/* Initialize OSABI common for GNU/Linux on 31- and 64-bit systems. */
static void
@@ -1152,6 +1193,9 @@ s390_linux_init_abi_any (struct gdbarch_info info, struct gdbarch *gdbarch)
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, s390_linux_get_tls_dtv_addr);
/* Support reverse debugging. */
set_gdbarch_process_record_signal (gdbarch, s390_linux_record_signal);
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 06/11] Internal, but disabled, TLS support for i386
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (4 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 05/11] Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 07/11] Delete disabled i386 internal TLS support Kevin Buettner
` (5 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This commit shows how internal TLS address lookup support could
be implemented for the i386 target.
Unfortunately, it doesn't work due to I386_GSBASE_REGNUM being
unavailable for Linux targets. I looked at trying to access the
gsbase register via PTRACE_GET_THREAD_AREA, but did not understand
it well enough to finish it. Since the i386 target is much less
important than it used to be, I gave up working on it.
I don't want to leave this disabled code in our sources, so I
will delete it in the next commit, however, this commit will be
in our git repo, so it'll be available for someone with sufficient
interest in the i386 target to look at.
---
gdb/i386-linux-tdep.c | 46 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/gdb/i386-linux-tdep.c b/gdb/i386-linux-tdep.c
index 2b7bd2b521f..d90fd9a4307 100644
--- a/gdb/i386-linux-tdep.c
+++ b/gdb/i386-linux-tdep.c
@@ -1237,6 +1237,47 @@ i386_linux_displaced_step_copy_insn (struct gdbarch *gdbarch,
return closure_;
}
+#if 0
+/* Disabled because fetching I386_GSBASE_REGNUM causes an internal
+ error. */
+
+#include "svr4-tls-tdep.h"
+
+/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
+ Throw a suitable TLS error if something goes wrong. */
+
+static CORE_ADDR
+i386_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
+ enum svr4_tls_libc libc)
+{
+ /* On i386, the thread pointer is found in the gsbase register. */
+ regcache *regcache
+ = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
+ target_fetch_registers (regcache, I386_GSBASE_REGNUM);
+ ULONGEST gsbase;
+ if (regcache->cooked_read (I386_GSBASE_REGNUM, &gsbase) != REG_VALID)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
+
+ /* The thread pointer (gsbase) points at the TCB (thread control
+ block). The first two members of this struct are both pointers,
+ where the first will be a pointer to the TCB (i.e. it points at
+ itself) and the second will be a pointer to the DTV (dynamic
+ thread vector). There are many other fields too, but the one
+ we care about here is the DTV pointer. Compute the address
+ of the DTV pointer, fetch it, and convert it to an address. */
+ CORE_ADDR dtv_ptr_addr
+ = gsbase + gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
+ gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
+ if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
+ throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
+
+ const struct builtin_type *builtin = builtin_type (gdbarch);
+ CORE_ADDR dtv_addr = gdbarch_pointer_to_address
+ (gdbarch, builtin->builtin_data_ptr, buf.data ());
+ return dtv_addr;
+}
+#endif
+
static void
i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
{
@@ -1472,6 +1513,11 @@ i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
+#if 0
+ set_gdbarch_get_thread_local_address (gdbarch,
+ svr4_tls_get_thread_local_address);
+ svr4_tls_register_tls_methods (info, gdbarch, i386_linux_get_tls_dtv_addr);
+#endif
/* Core file support. */
set_gdbarch_iterate_over_regset_sections
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 07/11] Delete disabled i386 internal TLS support
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (5 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 06/11] Internal, but disabled, TLS support for i386 Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 08/11] New test - gdb.base/tls-nothreads.exp Kevin Buettner
` (4 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
As mentioned in the previous commit, this commit deletes the disabled
code which could be used to implement internal TLS support for the
i386 target.
---
gdb/i386-linux-tdep.c | 46 -------------------------------------------
1 file changed, 46 deletions(-)
diff --git a/gdb/i386-linux-tdep.c b/gdb/i386-linux-tdep.c
index d90fd9a4307..2b7bd2b521f 100644
--- a/gdb/i386-linux-tdep.c
+++ b/gdb/i386-linux-tdep.c
@@ -1237,47 +1237,6 @@ i386_linux_displaced_step_copy_insn (struct gdbarch *gdbarch,
return closure_;
}
-#if 0
-/* Disabled because fetching I386_GSBASE_REGNUM causes an internal
- error. */
-
-#include "svr4-tls-tdep.h"
-
-/* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
- Throw a suitable TLS error if something goes wrong. */
-
-static CORE_ADDR
-i386_linux_get_tls_dtv_addr (struct gdbarch *gdbarch, ptid_t ptid,
- enum svr4_tls_libc libc)
-{
- /* On i386, the thread pointer is found in the gsbase register. */
- regcache *regcache
- = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
- target_fetch_registers (regcache, I386_GSBASE_REGNUM);
- ULONGEST gsbase;
- if (regcache->cooked_read (I386_GSBASE_REGNUM, &gsbase) != REG_VALID)
- throw_error (TLS_GENERIC_ERROR, _("Unable to fetch thread pointer"));
-
- /* The thread pointer (gsbase) points at the TCB (thread control
- block). The first two members of this struct are both pointers,
- where the first will be a pointer to the TCB (i.e. it points at
- itself) and the second will be a pointer to the DTV (dynamic
- thread vector). There are many other fields too, but the one
- we care about here is the DTV pointer. Compute the address
- of the DTV pointer, fetch it, and convert it to an address. */
- CORE_ADDR dtv_ptr_addr
- = gsbase + gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT;
- gdb::byte_vector buf (gdbarch_ptr_bit (gdbarch) / TARGET_CHAR_BIT);
- if (target_read_memory (dtv_ptr_addr, buf.data (), buf.size ()) != 0)
- throw_error (TLS_GENERIC_ERROR, _("Unable to fetch DTV address"));
-
- const struct builtin_type *builtin = builtin_type (gdbarch);
- CORE_ADDR dtv_addr = gdbarch_pointer_to_address
- (gdbarch, builtin->builtin_data_ptr, buf.data ());
- return dtv_addr;
-}
-#endif
-
static void
i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
{
@@ -1513,11 +1472,6 @@ i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
/* Enable TLS support. */
set_gdbarch_fetch_tls_load_module_address (gdbarch,
svr4_fetch_objfile_link_map);
-#if 0
- set_gdbarch_get_thread_local_address (gdbarch,
- svr4_tls_get_thread_local_address);
- svr4_tls_register_tls_methods (info, gdbarch, i386_linux_get_tls_dtv_addr);
-#endif
/* Core file support. */
set_gdbarch_iterate_over_regset_sections
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 08/11] New test - gdb.base/tls-nothreads.exp
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (6 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 07/11] Delete disabled i386 internal TLS support Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 09/11] New test - gdb.base/tls-multiobj.exp Kevin Buettner
` (3 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This commit introduces a new test, gdb.base/tls-nothreads.exp.
It has a test case, a C file, which has several TLS variables in the
main program, which, once compiled and linked, should end up (in ELF
files) in .tdata and .tbss. The test compiles the program in a number
of different ways, making sure that each variable is accessible
regardless of how it was compiled.
Note that some of the compilation scenarios end up with a statically
linked executable. Prior to this series of commits, accessing TLS
variables from a statically linked program on Linux did not work.
For certain targets (x86_64, aarch64, s390x, riscv, and ppc64),
all on Linux, support has been added to GDB for accessing thread
local storage in statically linked executables. This test is
important for testing those build scenarios.
But it's also important to make sure that GDB's internal TLS support
works for other scenarios too. In order to accomplish that, the
tests are also run in a mode which forces the internal support to
be used.
It also adds a new file, gdb.base/tls-common.exp.tcl, which includes
some common definitions used by the three new TLS tests, including
the one added by this commit. In particular, it sets a TCL variable,
'internal_tls_linux_targets' which list the targets mentioned earlier.
This means that as internal TLS support is added for other targets,
the target should be listed in just one file as opposed to three
(or more if other tests using tls-common.exp.tcl are added).
---
gdb/testsuite/gdb.base/tls-common.exp.tcl | 50 +++++
gdb/testsuite/gdb.base/tls-nothreads.c | 57 +++++
gdb/testsuite/gdb.base/tls-nothreads.exp | 248 ++++++++++++++++++++++
3 files changed, 355 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/tls-common.exp.tcl
create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.c
create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.exp
diff --git a/gdb/testsuite/gdb.base/tls-common.exp.tcl b/gdb/testsuite/gdb.base/tls-common.exp.tcl
new file mode 100644
index 00000000000..7aa7f466aa1
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-common.exp.tcl
@@ -0,0 +1,50 @@
+# Copyright 2024 Free Software Foundation, Inc.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Require statement, variables and procs used by tls-nothreads.exp,
+# tls-multiobj.exp, and tls-dlobj.exp.
+
+# The tests listed above are known to work for the targets listed on
+# the 'require' line, below.
+#
+# At the moment, only the Linux target is listed, but, ideally, these
+# tests should be run on other targets too. E.g, testing on FreeBSD
+# shows many failures which should be addressed in some fashion before
+# enabling it for that target.
+
+require {is_any_target "*-*-linux*"}
+
+# These are the targets which have support for internal TLS lookup:
+
+set internal_tls_linux_targets {"x86_64-*-linux*" "aarch64-*-linux*"
+ "riscv*-*-linux*" "powerpc64*-*-linux*"
+ "s390x*-*-linux*"}
+
+# The "maint set force-internal-tls-address-lookup" command is only
+# available for certain Linux architectures. Don't attempt to force
+# use of internal TLS support for architectures which don't support
+# it.
+
+if [is_any_target {*}$internal_tls_linux_targets] {
+ set internal_tls_iters { false true }
+} else {
+ set internal_tls_iters { false }
+}
+
+# Set up a kfail with message KFAIL_MSG when KFAIL_COND holds, then
+# issue gdb_test with command CMD and regular expression RE.
+
+proc gdb_test_with_kfail {cmd re kfail_cond kfail_msg} {
+ if [uplevel 1 [list expr $kfail_cond]] {
+ setup_kfail $kfail_msg *-*-*
+ }
+ gdb_test $cmd $re
+}
diff --git a/gdb/testsuite/gdb.base/tls-nothreads.c b/gdb/testsuite/gdb.base/tls-nothreads.c
new file mode 100644
index 00000000000..b3aaa3383e7
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-nothreads.c
@@ -0,0 +1,57 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+__thread int tls_tbss_1;
+__thread int tls_tbss_2;
+__thread int tls_tbss_3;
+
+__thread int tls_tdata_1 = 21;
+__thread int tls_tdata_2 = 22;
+__thread int tls_tdata_3 = 23;
+
+volatile int data;
+
+void
+use_it (int a)
+{
+ data = a;
+}
+
+int
+main (int argc, char **argv)
+{
+ use_it (-1);
+
+ tls_tbss_1 = 24; /* main-breakpoint-1 */
+ tls_tbss_2 = 25;
+ tls_tbss_3 = 26;
+
+ tls_tdata_1 = 42;
+ tls_tdata_2 = 43;
+ tls_tdata_3 = 44;
+
+ use_it (tls_tbss_1);
+ use_it (tls_tbss_2);
+ use_it (tls_tbss_3);
+ use_it (tls_tdata_1);
+ use_it (tls_tdata_2);
+ use_it (tls_tdata_3);
+
+ use_it (100); /* main-breakpoint-2 */
+
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.base/tls-nothreads.exp b/gdb/testsuite/gdb.base/tls-nothreads.exp
new file mode 100644
index 00000000000..edc49353daf
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-nothreads.exp
@@ -0,0 +1,248 @@
+# Copyright 2024 Free Software Foundation, Inc.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Using different compilation/linking scenarios, attempt to access
+# thread-local variables in a non-threaded program. Also test that
+# GDB internal TLS lookup works correctly.
+
+source $srcdir/$subdir/tls-common.exp.tcl
+
+standard_testfile
+
+proc do_tests {force_internal_tls {do_kfail_tls_access 0}} {
+ clean_restart $::binfile
+ if ![runto_main] {
+ return
+ }
+
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ if { $do_kfail_tls_access && [istarget "*-*-linux*"] } {
+ # Turn off do_kfail_tls_access when libthread_db is loaded.
+ # This can happen for the default case when testing x86_64
+ # w/ -m32 using glibc versions 2.34 or newer.
+ gdb_test_multiple "maint check libthread-db" "Check for loaded libthread_db" {
+ -re -wrap "libthread_db integrity checks passed." {
+ set do_kfail_tls_access 0
+ pass $gdb_test_name
+ }
+ -re -wrap "No libthread_db loaded" {
+ pass $gdb_test_name
+ }
+ }
+ # Also turn off do_kfail_tls_access when connected to a
+ # gdbserver and we observe that accessing a TLS variable
+ # works.
+ if [target_is_gdbserver] {
+ gdb_test_multiple "print tls_tbss_1" "Check TLS accessibility when connected to a gdbserver" {
+ -re -wrap "= 0" {
+ set do_kfail_tls_access 0
+ pass $gdb_test_name
+ }
+ -re -wrap "Remote target failed to process qGetTLSAddr request" {
+ pass $gdb_test_name
+ }
+ }
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-1"]
+ gdb_continue_to_breakpoint "main-breakpoint-1"
+
+ set t $do_kfail_tls_access
+ set m "tls not available"
+ with_test_prefix "before assignments" {
+ gdb_test_with_kfail "print tls_tbss_1" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_tbss_2" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_tbss_3" ".* = 0" $t $m
+
+ gdb_test_with_kfail "print tls_tdata_1" ".* = 21" $t $m
+ gdb_test_with_kfail "print tls_tdata_2" ".* = 22" $t $m
+ gdb_test_with_kfail "print tls_tdata_3" ".* = 23" $t $m
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-2"]
+ gdb_continue_to_breakpoint "main-breakpoint-2"
+
+ with_test_prefix "after assignments" {
+ gdb_test_with_kfail "print tls_tbss_1" ".* = 24" $t $m
+ gdb_test_with_kfail "print tls_tbss_2" ".* = 25" $t $m
+ gdb_test_with_kfail "print tls_tbss_3" ".* = 26" $t $m
+
+ gdb_test_with_kfail "print tls_tdata_1" ".* = 42" $t $m
+ gdb_test_with_kfail "print tls_tdata_2" ".* = 43" $t $m
+ gdb_test_with_kfail "print tls_tdata_3" ".* = 44" $t $m
+ }
+
+ # Make a core file now, but save testing using it until the end
+ # in case core files are not supported.
+ set corefile ${::binfile}.core
+ set core_supported 0
+ if { ![is_remote host] } {
+ set core_supported [gdb_gcore_cmd $corefile "save corefile"]
+ }
+
+ # Now continue to end and see what happens when attempting to
+ # access a TLS variable when the program is no longer running.
+ gdb_continue_to_end
+ with_test_prefix "after exit" {
+ gdb_test "print tls_tbss_1" \
+ "Cannot (?:read|find address of TLS symbol) `tls_tbss_1' without registers"
+ }
+
+ with_test_prefix "stripped" {
+ set binfile_stripped "${::binfile}.stripped"
+ set objcopy [gdb_find_objcopy]
+ set cmd "$objcopy --strip-debug ${::binfile} $binfile_stripped"
+ if ![catch "exec $cmd" cmd_output] {
+ clean_restart $binfile_stripped
+ if ![runto_main] {
+ return
+ }
+
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ # While there are no debug (e.g. DWARF) symbols, there
+ # are minimal symbols, so we should be able to place a
+ # breakpoint in use_it and continue to it. Continuing
+ # twice should put us past the assignments, at which point
+ # we can see if the TLS variables are still accessible.
+ gdb_test "break use_it" "Breakpoint 2 at $::hex"
+ gdb_test "continue" "Breakpoint 2, $::hex in use_it.*"
+ gdb_test "continue" "Breakpoint 2, $::hex in use_it.*" "continue 2"
+
+ # Note that a cast has been added in order to avoid the
+ # "...has unknown type; cast it to its declared type"
+ # problem.
+ gdb_test_with_kfail "print (int) tls_tbss_1" ".* = 24" $t $m
+ gdb_test_with_kfail "print (int) tls_tbss_2" ".* = 25" $t $m
+ gdb_test_with_kfail "print (int) tls_tbss_3" ".* = 26" $t $m
+
+ gdb_test_with_kfail "print (int) tls_tdata_1" ".* = 42" $t $m
+ gdb_test_with_kfail "print (int) tls_tdata_2" ".* = 43" $t $m
+ gdb_test_with_kfail "print (int) tls_tdata_3" ".* = 44" $t $m
+
+ # Get rid of the "use_it" breakpoint
+ gdb_test_no_output "del 2"
+
+ # Continue to program exit
+ gdb_continue_to_end
+
+ # TLS variables should not be accessible after program exit
+ # (This case initially caused GDB to crash during development
+ # of GDB-internal TLS lookup support.)
+ with_test_prefix "after exit" {
+ gdb_test "print (int) tls_tbss_1" \
+ "Cannot find address of TLS symbol `tls_tbss_1' without registers"
+ }
+ }
+ }
+
+ # Finish test early if no core file was made.
+ if !$core_supported {
+ return
+ }
+
+ clean_restart $::binfile
+
+ set core_loaded [gdb_core_cmd $corefile "load corefile"]
+ if { $core_loaded == -1 } {
+ return
+ }
+
+ with_test_prefix "core file" {
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ gdb_test_with_kfail "print tls_tbss_1" ".* = 24" $t $m
+ gdb_test_with_kfail "print tls_tbss_2" ".* = 25" $t $m
+ gdb_test_with_kfail "print tls_tbss_3" ".* = 26" $t $m
+
+ gdb_test_with_kfail "print tls_tdata_1" ".* = 42" $t $m
+ gdb_test_with_kfail "print tls_tdata_2" ".* = 43" $t $m
+ gdb_test_with_kfail "print tls_tdata_3" ".* = 44" $t $m
+ }
+}
+
+# Certain linux target architectures implement support for internal
+# TLS lookup which is used when thread stratum support (via
+# libthread_db) is missing or when the linux-only GDB maintenance
+# setting 'force-internal-tls-address-lookup' is 'on'. Thus for some
+# of the testing scenarios, such as statically linked executables,
+# this internal support will be used. Set 'do_kfail_tls_access' to 1
+# for those architectures which don't implement internal TLS support.
+if {[istarget *-*-linux*]
+ && ![is_any_target {*}$internal_tls_linux_targets]} {
+ set do_kfail_tls_access 1
+} elseif {[istarget *-*-linux*] && [is_x86_like_target]} {
+ # This covers the case of x86_64 with -m32:
+ set do_kfail_tls_access 1
+} else {
+ set do_kfail_tls_access 0
+}
+
+set binprefix $binfile
+
+with_test_prefix "default" {
+ set binfile $binprefix-default
+ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ # Depending on glibc version, it might not be appropriate
+ # for do_kfail_tls_access to be set here. That will be
+ # handled in 'do_tests', disabling it if necessary.
+ #
+ # Specifically, glibc versions 2.34 and later have the
+ # thread library (and libthread_db availability) in
+ # programs not linked against libpthread.so
+ do_tests $force_internal_tls $do_kfail_tls_access
+ }
+ }
+}
+
+with_test_prefix "static" {
+ set binfile $binprefix-static
+ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug "additional_flags=-static"}] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ do_tests $force_internal_tls $do_kfail_tls_access
+ }
+ }
+}
+
+with_test_prefix "pthreads" {
+ set binfile $binprefix-pthreads
+ if { [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ do_tests $force_internal_tls
+ }
+ }
+}
+
+with_test_prefix "pthreads-static" {
+ set binfile $binprefix-pthreads-static
+ if { [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug "additional_flags=-static"}] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ do_tests $force_internal_tls $do_kfail_tls_access
+ }
+ }
+}
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 09/11] New test - gdb.base/tls-multiobj.exp
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (7 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 08/11] New test - gdb.base/tls-nothreads.exp Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 10/11] New test - gdb.base/tls-dlobj.exp Kevin Buettner
` (2 subsequent siblings)
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This test exercises GDB's internal TLS support when both the main
program and several shared libraries have TLS variables. It also
tests existing (non-internal) TLS support too.
It tests using two compilation scenarios, "default", in which
libpthread is not linked with the program and libraries as well
as one which does use libpthread.
It tests link map address to module id mapping code in GDB
in addition to the ability of GDB to traverse TLS data structures
with several libraries in play.
---
gdb/testsuite/gdb.base/tls-multiobj.c | 89 +++++++++
gdb/testsuite/gdb.base/tls-multiobj.exp | 230 ++++++++++++++++++++++++
gdb/testsuite/gdb.base/tls-multiobj1.c | 26 +++
gdb/testsuite/gdb.base/tls-multiobj2.c | 26 +++
gdb/testsuite/gdb.base/tls-multiobj3.c | 26 +++
5 files changed, 397 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.c
create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.exp
create mode 100644 gdb/testsuite/gdb.base/tls-multiobj1.c
create mode 100644 gdb/testsuite/gdb.base/tls-multiobj2.c
create mode 100644 gdb/testsuite/gdb.base/tls-multiobj3.c
diff --git a/gdb/testsuite/gdb.base/tls-multiobj.c b/gdb/testsuite/gdb.base/tls-multiobj.c
new file mode 100644
index 00000000000..10e67da54d8
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-multiobj.c
@@ -0,0 +1,89 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+__thread int tls_main_tbss_1;
+__thread int tls_main_tbss_2;
+__thread int tls_main_tdata_1 = 96;
+__thread int tls_main_tdata_2 = 97;
+
+extern __thread int tls_lib1_tbss_1;
+extern __thread int tls_lib1_tbss_2;
+extern __thread int tls_lib1_tdata_1;
+extern __thread int tls_lib1_tdata_2;
+
+extern __thread int tls_lib2_tbss_1;
+extern __thread int tls_lib2_tbss_2;
+extern __thread int tls_lib2_tdata_1;
+extern __thread int tls_lib2_tdata_2;
+
+extern __thread int tls_lib3_tbss_1;
+extern __thread int tls_lib3_tbss_2;
+extern __thread int tls_lib3_tdata_1;
+extern __thread int tls_lib3_tdata_2;
+
+extern void lib1_func ();
+extern void lib2_func ();
+extern void lib3_func ();
+
+volatile int data;
+
+void
+use_it (int a)
+{
+ data = a;
+}
+
+int
+main (int argc, char **argv)
+{
+ use_it (-1);
+
+ tls_main_tbss_1 = 51; /* main-breakpoint-1 */
+ tls_main_tbss_2 = 52;
+ tls_main_tdata_1 = 53;
+ tls_main_tdata_2 = 54;
+
+ tls_lib1_tbss_1 = 151;
+ tls_lib1_tbss_2 = 152;
+ tls_lib1_tdata_1 = 153;
+ tls_lib1_tdata_2 = 154;
+
+ tls_lib2_tbss_1 = 251;
+ tls_lib2_tbss_2 = 252;
+ tls_lib2_tdata_1 = 253;
+ tls_lib2_tdata_2 = 254;
+
+ tls_lib3_tbss_1 = 351;
+ tls_lib3_tbss_2 = 352;
+ tls_lib3_tdata_1 = 353;
+ tls_lib3_tdata_2 = 354;
+
+ lib1_func ();
+ lib2_func ();
+ lib3_func ();
+
+ /* Attempt to keep variables in the main program from being optimized
+ away. */
+ use_it (tls_main_tbss_1);
+ use_it (tls_main_tbss_2);
+ use_it (tls_main_tdata_1);
+ use_it (tls_main_tdata_2);
+
+ use_it (100); /* main-breakpoint-2 */
+
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.base/tls-multiobj.exp b/gdb/testsuite/gdb.base/tls-multiobj.exp
new file mode 100644
index 00000000000..a78db1460e9
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-multiobj.exp
@@ -0,0 +1,230 @@
+# Copyright 2024 Free Software Foundation, Inc.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Using different compilation/linking scenarios, attempt to access
+# thread-local variables in a non-threaded program using multiple
+# shared objects.
+
+source $srcdir/$subdir/tls-common.exp.tcl
+
+standard_testfile
+
+set lib1src "${srcdir}/${subdir}/${testfile}1.c"
+set lib2src "${srcdir}/${subdir}/${testfile}2.c"
+set lib3src "${srcdir}/${subdir}/${testfile}3.c"
+
+set lib1obj [standard_output_file "${testfile}1-lib.so"]
+set lib2obj [standard_output_file "${testfile}2-lib.so"]
+set lib3obj [standard_output_file "${testfile}3-lib.so"]
+
+proc do_tests {force_internal_tls {do_kfail_tls_access 0}} {
+ clean_restart $::binfile
+ if ![runto_main] {
+ return
+ }
+
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ if { $do_kfail_tls_access && [istarget "*-*-linux*"] } {
+ # Turn off do_kfail_tls_access when libthread_db is loaded.
+ # This can happen for the default case when testing x86_64
+ # w/ -m32 using glibc versions 2.34 or newer.
+ gdb_test_multiple "maint check libthread-db" "Check for loaded libthread_db" {
+ -re -wrap "libthread_db integrity checks passed." {
+ set do_kfail_tls_access 0
+ pass $gdb_test_name
+ }
+ -re -wrap "No libthread_db loaded" {
+ pass $gdb_test_name
+ }
+ }
+ # Also turn off do_kfail_tls_access when connected to a
+ # gdbserver and we observe that accessing a TLS variable
+ # works.
+ if [target_is_gdbserver] {
+ gdb_test_multiple "print tls_main_tbss_1" \
+ "Check TLS accessibility when connected to a gdbserver" {
+ -re -wrap "= 0" {
+ set do_kfail_tls_access 0
+ pass $gdb_test_name
+ }
+ -re -wrap "Remote target failed to process qGetTLSAddr request" {
+ pass $gdb_test_name
+ }
+ }
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-1"]
+ gdb_continue_to_breakpoint "main-breakpoint-1"
+
+ set t $do_kfail_tls_access
+ set m "tls not available"
+ with_test_prefix "before assignments" {
+ gdb_test_with_kfail "print tls_main_tbss_1" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_main_tbss_2" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_1" ".* = 96" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_2" ".* = 97" $t $m
+
+ gdb_test_with_kfail "print tls_lib1_tbss_1" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib1_tbss_2" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_1" ".* = 196" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_2" ".* = 197" $t $m
+
+ gdb_test_with_kfail "print tls_lib2_tbss_1" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib2_tbss_2" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_1" ".* = 296" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_2" ".* = 297" $t $m
+
+ gdb_test_with_kfail "print tls_lib3_tbss_1" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib3_tbss_2" ".* = 0" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_1" ".* = 396" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_2" ".* = 397" $t $m
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-2"]
+ gdb_continue_to_breakpoint "main-breakpoint-2"
+
+ with_test_prefix "after assignments" {
+ gdb_test_with_kfail "print tls_main_tbss_1" ".* = 51" $t $m
+ gdb_test_with_kfail "print tls_main_tbss_2" ".* = 52" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_1" ".* = 53" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_2" ".* = 54" $t $m
+
+ gdb_test_with_kfail "print tls_lib1_tbss_1" ".* = 151" $t $m
+ gdb_test_with_kfail "print tls_lib1_tbss_2" ".* = 152" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_1" ".* = 153" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_2" ".* = 154" $t $m
+
+ gdb_test_with_kfail "print tls_lib2_tbss_1" ".* = 251" $t $m
+ gdb_test_with_kfail "print tls_lib2_tbss_2" ".* = 252" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_1" ".* = 253" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_2" ".* = 254" $t $m
+
+ gdb_test_with_kfail "print tls_lib3_tbss_1" ".* = 351" $t $m
+ gdb_test_with_kfail "print tls_lib3_tbss_2" ".* = 352" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_1" ".* = 353" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_2" ".* = 354" $t $m
+ }
+
+ set corefile ${::binfile}.core
+ set core_supported 0
+ if { ![is_remote host] } {
+ set core_supported [gdb_gcore_cmd $corefile "save corefile"]
+ }
+
+ # Finish test early if no core file was made.
+ if !$core_supported {
+ return
+ }
+
+ clean_restart $::binfile
+
+ set core_loaded [gdb_core_cmd $corefile "load corefile"]
+ if { $core_loaded == -1 } {
+ return
+ }
+
+ with_test_prefix "core file" {
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ gdb_test_with_kfail "print tls_main_tbss_1" ".* = 51" $t $m
+ gdb_test_with_kfail "print tls_main_tbss_2" ".* = 52" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_1" ".* = 53" $t $m
+ gdb_test_with_kfail "print tls_main_tdata_2" ".* = 54" $t $m
+
+ gdb_test_with_kfail "print tls_lib1_tbss_1" ".* = 151" $t $m
+ gdb_test_with_kfail "print tls_lib1_tbss_2" ".* = 152" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_1" ".* = 153" $t $m
+ gdb_test_with_kfail "print tls_lib1_tdata_2" ".* = 154" $t $m
+
+ gdb_test_with_kfail "print tls_lib2_tbss_1" ".* = 251" $t $m
+ gdb_test_with_kfail "print tls_lib2_tbss_2" ".* = 252" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_1" ".* = 253" $t $m
+ gdb_test_with_kfail "print tls_lib2_tdata_2" ".* = 254" $t $m
+
+ gdb_test_with_kfail "print tls_lib3_tbss_1" ".* = 351" $t $m
+ gdb_test_with_kfail "print tls_lib3_tbss_2" ".* = 352" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_1" ".* = 353" $t $m
+ gdb_test_with_kfail "print tls_lib3_tdata_2" ".* = 354" $t $m
+ }
+}
+
+if { [gdb_compile_shlib $lib1src $lib1obj {debug}] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $lib2src $lib2obj {debug}] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $lib3src $lib3obj {debug}] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+
+# Certain linux target architectures implement support for internal
+# TLS lookup which is used when thread stratum support (via
+# libthread_db) is missing or when the linux-only GDB maintenance
+# setting 'force-internal-tls-address-lookup' is 'on'. Thus for some
+# of the testing scenarios, such as statically linked executables,
+# this internal support will be used. Set 'do_kfail_tls_access' to 1
+# for those architectures which don't implement internal tls support.
+if {[istarget *-*-linux*]
+ && ![is_any_target {*}$internal_tls_linux_targets]} {
+ set do_kfail_tls_access 1
+} elseif {[istarget *-*-linux*] && [is_x86_like_target]} {
+ # This covers the case of x86_64 with -m32:
+ set do_kfail_tls_access 1
+} else {
+ set do_kfail_tls_access 0
+}
+
+set binprefix $binfile
+
+with_test_prefix "default" {
+ set binfile $binprefix-default
+ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable \
+ [list debug shlib=${lib1obj} \
+ shlib=${lib2obj} \
+ shlib=${lib3obj}]] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ # Depending on glibc version, it might not be appropriate
+ # for do_kfail_tls_access to be set here. That will be
+ # handled in 'do_tests', disabling it if necessary.
+ #
+ # Specifically, glibc versions 2.34 and later have the
+ # thread library (and libthread_db availability) in
+ # programs not linked against libpthread.so
+ do_tests $force_internal_tls $do_kfail_tls_access
+ }
+ }
+}
+
+with_test_prefix "pthreads" {
+ set binfile $binprefix-pthreads
+ if { [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable \
+ [list debug shlib=${lib1obj} \
+ shlib=${lib2obj} \
+ shlib=${lib3obj}]] != "" } {
+ untested "failed to compile"
+ } else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ do_tests $force_internal_tls
+ }
+ }
+}
diff --git a/gdb/testsuite/gdb.base/tls-multiobj1.c b/gdb/testsuite/gdb.base/tls-multiobj1.c
new file mode 100644
index 00000000000..86e72228b1b
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-multiobj1.c
@@ -0,0 +1,26 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+__thread int tls_lib1_tbss_1;
+__thread int tls_lib1_tbss_2;
+__thread int tls_lib1_tdata_1 = 196;
+__thread int tls_lib1_tdata_2 = 197;
+
+void
+lib1_func ()
+{
+}
diff --git a/gdb/testsuite/gdb.base/tls-multiobj2.c b/gdb/testsuite/gdb.base/tls-multiobj2.c
new file mode 100644
index 00000000000..cea07092a5d
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-multiobj2.c
@@ -0,0 +1,26 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+__thread int tls_lib2_tbss_1;
+__thread int tls_lib2_tbss_2;
+__thread int tls_lib2_tdata_1 = 296;
+__thread int tls_lib2_tdata_2 = 297;
+
+void
+lib2_func ()
+{
+}
diff --git a/gdb/testsuite/gdb.base/tls-multiobj3.c b/gdb/testsuite/gdb.base/tls-multiobj3.c
new file mode 100644
index 00000000000..bb0f2395fbf
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-multiobj3.c
@@ -0,0 +1,26 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+__thread int tls_lib3_tbss_1;
+__thread int tls_lib3_tbss_2;
+__thread int tls_lib3_tdata_1 = 396;
+__thread int tls_lib3_tdata_2 = 397;
+
+void
+lib3_func ()
+{
+}
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 10/11] New test - gdb.base/tls-dlobj.exp
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (8 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 09/11] New test - gdb.base/tls-multiobj.exp Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-04 23:37 ` [PATCH v6 11/11] Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command Kevin Buettner
2025-04-18 18:36 ` [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
This test exercises musl_link_map_to_tls_module_id() and
glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c.
Prior to writing this test, I had only written what is now named
'musl_link_map_to_tls_module_id' and it worked for both GLIBC and
MUSL. Once I wrote this new test, tls-dlobj.exp, there were a number
of tests which didn't work with GLIBC. This led me to write a
GLIBC-specific link map to module id function, i.e,
'glibc_link_map_to_tls_module_id'.
It only has one compilation scenario, in which the pthread(s) library
is used - as noted in a comment, it became too much of a hassle to try
to KFAIL things, though it certainly could have been done in much the
same was as was done in gdb.base/multiobj.exp. It didn't seem that
important to do so, however, since I believe that the other tests
have adequate coverage for different compilation scenarios.
---
gdb/testsuite/gdb.base/tls-dlobj-lib.c | 87 ++++++
gdb/testsuite/gdb.base/tls-dlobj.c | 311 ++++++++++++++++++++
gdb/testsuite/gdb.base/tls-dlobj.exp | 378 +++++++++++++++++++++++++
3 files changed, 776 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/tls-dlobj-lib.c
create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.c
create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.exp
diff --git a/gdb/testsuite/gdb.base/tls-dlobj-lib.c b/gdb/testsuite/gdb.base/tls-dlobj-lib.c
new file mode 100644
index 00000000000..3f8ebc4f6a7
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-dlobj-lib.c
@@ -0,0 +1,87 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* This program needs to be compiled with preprocessor symbol set to
+ a small integer, e.g. "gcc -DN=1 ..." With N defined, the CONCAT2
+ and CONCAT3 macros will construct suitable names for the global
+ variables and functions. */
+
+#define CONCAT2(a,b) CONCAT2_(a,b)
+#define CONCAT2_(a,b) a ## b
+
+#define CONCAT3(a,b,c) CONCAT3_(a,b,c)
+#define CONCAT3_(a,b,c) a ## b ## c
+
+/* For N=1, this ends up being...
+ __thread int tls_lib1_tbss_1;
+ __thread int tls_lib1_tbss_2;
+ __thread int tls_lib1_tdata_1 = 196;
+ __thread int tls_lib1_tdata_2 = 197; */
+
+__thread int CONCAT3(tls_lib, N, _tbss_1);
+__thread int CONCAT3(tls_lib, N, _tbss_2);
+__thread int CONCAT3(tls_lib, N, _tdata_1) = CONCAT2(N, 96);
+__thread int CONCAT3(tls_lib, N, _tdata_2) = CONCAT2(N, 97);
+
+/* Substituting for N, define function:
+
+ int get_tls_libN_var (int which) . */
+
+int
+CONCAT3(get_tls_lib, N, _var) (int which)
+{
+ switch (which)
+ {
+ case 0:
+ return -1;
+ case 1:
+ return CONCAT3(tls_lib, N, _tbss_1);
+ case 2:
+ return CONCAT3(tls_lib, N, _tbss_2);
+ case 3:
+ return CONCAT3(tls_lib, N, _tdata_1);
+ case 4:
+ return CONCAT3(tls_lib, N, _tdata_2);
+ }
+ return -1;
+}
+
+/* Substituting for N, define function:
+
+ void set_tls_libN_var (int which, int val) . */
+
+void
+CONCAT3(set_tls_lib, N, _var) (int which, int val)
+{
+ switch (which)
+ {
+ case 0:
+ break;
+ case 1:
+ CONCAT3(tls_lib, N, _tbss_1) = val;
+ break;
+ case 2:
+ CONCAT3(tls_lib, N, _tbss_2) = val;
+ break;
+ case 3:
+ CONCAT3(tls_lib, N, _tdata_1) = val;
+ break;
+ case 4:
+ CONCAT3(tls_lib, N, _tdata_2) = val;
+ break;
+ }
+}
diff --git a/gdb/testsuite/gdb.base/tls-dlobj.c b/gdb/testsuite/gdb.base/tls-dlobj.c
new file mode 100644
index 00000000000..322bdda0393
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-dlobj.c
@@ -0,0 +1,311 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2024 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include <dlfcn.h>
+#include <assert.h>
+#include <stdlib.h>
+#include <stdio.h>
+
+typedef void (*setter_ftype) (int which, int val);
+
+__thread int tls_main_tbss_1;
+__thread int tls_main_tbss_2;
+__thread int tls_main_tdata_1 = 96;
+__thread int tls_main_tdata_2 = 97;
+
+extern void set_tls_lib10_var (int which, int val);
+extern void set_tls_lib11_var (int which, int val);
+
+volatile int data;
+
+static void
+set_tls_main_var (int which, int val)
+{
+ switch (which)
+ {
+ case 1:
+ tls_main_tbss_1 = val;
+ break;
+ case 2:
+ tls_main_tbss_2 = val;
+ break;
+ case 3:
+ tls_main_tdata_1 = val;
+ break;
+ case 4:
+ tls_main_tdata_2 = val;
+ break;
+ }
+}
+
+void
+use_it (int a)
+{
+ data = a;
+}
+
+static void *
+load_dso (char *dso_name, int n, setter_ftype *setterp)
+{
+ char buf[80];
+ void *sym;
+ void *handle = dlopen (dso_name, RTLD_NOW | RTLD_GLOBAL);
+ if (handle == NULL)
+ {
+ fprintf (stderr, "dlopen of DSO '%s' failed: %s\n", dso_name, dlerror ());
+ exit (1);
+ }
+ sprintf (buf, "set_tls_lib%d_var", n);
+ sym = dlsym (handle, buf);
+ assert (sym != NULL);
+ *setterp = sym;
+
+ /* Some libc implementations (for some architectures) refuse to
+ initialize TLS data structures (specifically, the DTV) without
+ first calling dlsym on one of the TLS symbols. */
+ sprintf (buf, "tls_lib%d_tdata_1", n);
+ assert (dlsym (handle, buf) != NULL);
+
+ return handle;
+}
+
+int
+main (int argc, char **argv)
+{
+ int i, status;
+ setter_ftype s0, s1, s2, s3, s4, s10, s11;
+ void *h1 = load_dso (OBJ1, 1, &s1);
+ void *h2 = load_dso (OBJ2, 2, &s2);
+ void *h3 = load_dso (OBJ3, 3, &s3);
+ void *h4 = load_dso (OBJ4, 4, &s4);
+ s0 = set_tls_main_var;
+ s10 = set_tls_lib10_var;
+ s11 = set_tls_lib11_var;
+
+ use_it (0); /* main-breakpoint-1 */
+
+ /* Set TLS variables in main program and all libraries. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 10 + i);
+ for (i = 1; i <= 4; i++)
+ s1 (i, 110 + i);
+ for (i = 1; i <= 4; i++)
+ s2 (i, 210 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 310 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 410 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1010 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1110 + i);
+
+ use_it (0); /* main-breakpoint-2 */
+
+ /* Unload lib2 and lib3. */
+ status = dlclose (h2);
+ assert (status == 0);
+ status = dlclose (h3);
+ assert (status == 0);
+
+ /* Set TLS variables in main program and in libraries which are still
+ loaded. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 20 + i);
+ for (i = 1; i <= 4; i++)
+ s1 (i, 120 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 420 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1020 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1120 + i);
+
+ use_it (0); /* main-breakpoint-3 */
+
+ /* Load lib3. */
+ h3 = load_dso (OBJ3, 3, &s3);
+
+ /* Set TLS vars again; currently, only lib2 is not loaded. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 30 + i);
+ for (i = 1; i <= 4; i++)
+ s1 (i, 130 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 330 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 430 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1030 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1130 + i);
+
+ use_it (0); /* main-breakpoint-4 */
+
+ /* Unload lib1 and lib4; load lib2. */
+ status = dlclose (h1);
+ assert (status == 0);
+ status = dlclose (h4);
+ assert (status == 0);
+ h2 = load_dso (OBJ2, 2, &s2);
+
+ /* Set TLS vars; currently, lib2 and lib3 are loaded,
+ lib1 and lib4 are not. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 40 + i);
+ for (i = 1; i <= 4; i++)
+ s2 (i, 240 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 340 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1040 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1140 + i);
+
+ use_it (0); /* main-breakpoint-5 */
+
+ /* Load lib4 and lib1. Unload lib2. */
+ h4 = load_dso (OBJ4, 4, &s4);
+ h1 = load_dso (OBJ1, 1, &s1);
+ status = dlclose (h2);
+ assert (status == 0);
+
+ /* Set TLS vars; currently, lib1, lib3, and lib4 are loaded;
+ lib2 is not loaded. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 50 + i);
+ for (i = 1; i <= 4; i++)
+ s1 (i, 150 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 350 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 450 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1050 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1150 + i);
+
+ use_it (0); /* main-breakpoint-6 */
+
+ /* Load lib2, unload lib1, lib3, and lib4; then load lib3 again. */
+ h2 = load_dso (OBJ2, 2, &s2);
+ status = dlclose (h1);
+ assert (status == 0);
+ status = dlclose (h3);
+ assert (status == 0);
+ status = dlclose (h4);
+ assert (status == 0);
+ h3 = load_dso (OBJ3, 3, &s3);
+
+ /* Set TLS vars; currently, lib2 and lib3 are loaded;
+ lib1 and lib4 are not loaded. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 60 + i);
+ for (i = 1; i <= 4; i++)
+ s2 (i, 260 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 360 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1060 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1160 + i);
+
+ use_it (0); /* main-breakpoint-7 */
+
+ /* Unload lib3 and lib2, then (re)load lib4, lib3, lib2, and lib1,
+ in that order. */
+ status = dlclose (h3);
+ assert (status == 0);
+ status = dlclose (h2);
+ assert (status == 0);
+ h4 = load_dso (OBJ4, 4, &s4);
+ h3 = load_dso (OBJ3, 3, &s3);
+ h2 = load_dso (OBJ2, 2, &s2);
+ h1 = load_dso (OBJ1, 1, &s1);
+
+ /* Set TLS vars; currently, lib1, lib2, lib3, and lib4 are all
+ loaded. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 70 + i);
+ for (i = 1; i <= 4; i++)
+ s1 (i, 170 + i);
+ for (i = 1; i <= 4; i++)
+ s2 (i, 270 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 370 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 470 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1070 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1170 + i);
+
+ use_it (0); /* main-breakpoint-8 */
+
+ /* Unload lib3, lib1, and lib4. */
+ status = dlclose (h3);
+ assert (status == 0);
+ status = dlclose (h1);
+ assert (status == 0);
+ status = dlclose (h4);
+ assert (status == 0);
+
+ /* Set TLS vars; currently, lib2 is loaded; lib1, lib3, and lib4 are
+ not. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 80 + i);
+ for (i = 1; i <= 4; i++)
+ s2 (i, 280 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1080 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1180 + i);
+
+ use_it (0); /* main-breakpoint-9 */
+
+ /* Load lib3, unload lib2, load lib4. */
+ h3 = load_dso (OBJ3, 3, &s3);
+ status = dlclose (h2);
+ assert (status == 0);
+ h4 = load_dso (OBJ4, 4, &s4);
+
+ /* Set TLS vars; currently, lib3 and lib4 are loaded; lib1 and lib2
+ are not. */
+ for (i = 1; i <= 4; i++)
+ s0 (i, 90 + i);
+ for (i = 1; i <= 4; i++)
+ s3 (i, 390 + i);
+ for (i = 1; i <= 4; i++)
+ s4 (i, 490 + i);
+ for (i = 1; i <= 4; i++)
+ s10 (i, 1090 + i);
+ for (i = 1; i <= 4; i++)
+ s11 (i, 1190 + i);
+
+ use_it (0); /* main-breakpoint-10 */
+
+ /* Attempt to keep variables in the main program from being optimized
+ away. */
+ use_it (tls_main_tbss_1);
+ use_it (tls_main_tbss_2);
+ use_it (tls_main_tdata_1);
+ use_it (tls_main_tdata_2);
+
+ use_it (100); /* main-breakpoint-last */
+
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.base/tls-dlobj.exp b/gdb/testsuite/gdb.base/tls-dlobj.exp
new file mode 100644
index 00000000000..02f2ff81219
--- /dev/null
+++ b/gdb/testsuite/gdb.base/tls-dlobj.exp
@@ -0,0 +1,378 @@
+# Copyright 2024 Free Software Foundation, Inc.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# Test that the GDB-internal TLS link map to module id mapping code
+# works correctly when debugging a program which is linked against
+# shared objects and which also loads and unloads other shared objects
+# in different orders. For targets which have GDB-internal TLS
+# support, it'll check both GDB-internal TLS support as well as that
+# provided by a helper library such as libthread_db.
+
+source $srcdir/$subdir/tls-common.exp.tcl
+
+require allow_shlib_tests
+
+standard_testfile
+
+set libsrc "${srcdir}/${subdir}/${testfile}-lib.c"
+
+# These will be dlopen'd:
+set lib1obj [standard_output_file "${testfile}1-lib.so"]
+set lib2obj [standard_output_file "${testfile}2-lib.so"]
+set lib3obj [standard_output_file "${testfile}3-lib.so"]
+set lib4obj [standard_output_file "${testfile}4-lib.so"]
+
+# These will be dynamically linked with the main program:
+set lib10obj [standard_output_file "${testfile}10-lib.so"]
+set lib11obj [standard_output_file "${testfile}11-lib.so"]
+
+# Due to problems with some versions of glibc, we expect some tests to
+# fail due to TLS storage not being allocated/initialized. Test
+# command CMD using regular expression RE, and use XFAIL instead of
+# FAIL when the relevant RE is matched and COND is true when evaluated
+# in the upper level.
+
+proc gdb_test_with_xfail { cmd re cond} {
+ gdb_test_multiple $cmd $cmd {
+ -re -wrap $re {
+ pass $gdb_test_name
+ }
+ -re -wrap "The inferior has not yet allocated storage for thread-local variables.*" {
+ if [ uplevel 1 [list expr $cond]] {
+ xfail $gdb_test_name
+ } else {
+ fail $gdb_test_name
+ }
+ }
+ }
+}
+
+proc do_tests {force_internal_tls} {
+ clean_restart $::binfile
+ if ![runto_main] {
+ return
+ }
+
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-1"]
+ gdb_continue_to_breakpoint "main-breakpoint-1"
+
+ with_test_prefix "before assignments" {
+ gdb_test "print tls_main_tbss_1" ".* = 0"
+ gdb_test "print tls_main_tbss_2" ".* = 0"
+ gdb_test "print tls_main_tdata_1" ".* = 96"
+ gdb_test "print tls_main_tdata_2" ".* = 97"
+
+ # For these tests, where we're attempting to access TLS vars
+ # in a dlopen'd library, but before assignment to any of the
+ # vars, so it could happen that storage hasn't been allocated
+ # yet. But it might also work. (When testing against MUSL,
+ # things just work; GLIBC ends to produce the TLS error.) So
+ # accept either the right answer or a TLS error message.
+
+ set tlserr "The inferior has not yet allocated storage for thread-local variables.*"
+ foreach n {1 2 3 4} {
+ gdb_test "print tls_lib${n}_tbss_1" \
+ "0|${tlserr}"
+ gdb_test "print tls_lib${n}_tbss_2" \
+ "0|${tlserr}"
+ gdb_test "print tls_lib${n}_tdata_1" \
+ "96|${tlserr}"
+ gdb_test "print tls_lib${n}_tdata_2" \
+ "97|${tlserr}"
+ }
+ foreach n {10 11} {
+ gdb_test "print tls_lib${n}_tbss_1" ".* = 0"
+ gdb_test "print tls_lib${n}_tbss_2" ".* = 0"
+ gdb_test "print tls_lib${n}_tdata_1" ".* = ${n}96"
+ gdb_test "print tls_lib${n}_tdata_2" ".* = ${n}97"
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-2"]
+ gdb_continue_to_breakpoint "main-breakpoint-2"
+
+ with_test_prefix "at main-breakpoint-2" {
+ gdb_test "print tls_main_tbss_1" ".* = 11"
+ gdb_test "print tls_main_tbss_2" ".* = 12"
+ gdb_test "print tls_main_tdata_1" ".* = 13"
+ gdb_test "print tls_main_tdata_2" ".* = 14"
+
+ foreach n {1 2 3 4 10 11} {
+ gdb_test "print tls_lib${n}_tbss_1" ".* = ${n}11"
+ gdb_test "print tls_lib${n}_tbss_2" ".* = ${n}12"
+ gdb_test "print tls_lib${n}_tdata_1" ".* = ${n}13"
+ gdb_test "print tls_lib${n}_tdata_2" ".* = ${n}14"
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-3"]
+ gdb_continue_to_breakpoint "main-breakpoint-3"
+
+ # At this point lib2 and lib3 have been unloaded. Also, TLS vars
+ # in remaining libraries have been changed.
+
+ with_test_prefix "at main-breakpoint-3" {
+ gdb_test "print tls_main_tbss_1" ".* = 21"
+ gdb_test "print tls_main_tbss_2" ".* = 22"
+ gdb_test "print tls_main_tdata_1" ".* = 23"
+ gdb_test "print tls_main_tdata_2" ".* = 24"
+
+ foreach n {1 4 10 11} {
+ gdb_test "print tls_lib${n}_tbss_1" ".* = ${n}21"
+ gdb_test "print tls_lib${n}_tbss_2" ".* = ${n}22"
+ gdb_test "print tls_lib${n}_tdata_1" ".* = ${n}23"
+ gdb_test "print tls_lib${n}_tdata_2" ".* = ${n}24"
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-4"]
+ gdb_continue_to_breakpoint "main-breakpoint-4"
+
+ # lib3 has been loaded again; lib2 is the only one not loaded.
+
+ with_test_prefix "at main-breakpoint-4" {
+ gdb_test "print tls_main_tbss_1" ".* = 31"
+ gdb_test "print tls_main_tbss_2" ".* = 32"
+ gdb_test "print tls_main_tdata_1" ".* = 33"
+ gdb_test "print tls_main_tdata_2" ".* = 34"
+
+ set cond { $n == 3 }
+ foreach n {1 3 4 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}31" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}32" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}33" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}34" $cond
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-5"]
+ gdb_continue_to_breakpoint "main-breakpoint-5"
+
+ # lib2 and lib3 are loaded; lib1 and lib4 are not.
+
+ with_test_prefix "at main-breakpoint-5" {
+ gdb_test "print tls_main_tbss_1" ".* = 41"
+ gdb_test "print tls_main_tbss_2" ".* = 42"
+ gdb_test "print tls_main_tdata_1" ".* = 43"
+ gdb_test "print tls_main_tdata_2" ".* = 44"
+
+ set cond { $n == 2 || $n == 3 }
+ foreach n {2 3 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}41" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}42" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}43" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}44" $cond
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-6"]
+ gdb_continue_to_breakpoint "main-breakpoint-6"
+
+ # lib1, lib3 and lib4 are loaded; lib2 is not loaded.
+
+ with_test_prefix "at main-breakpoint-6" {
+ gdb_test "print tls_main_tbss_1" ".* = 51"
+ gdb_test "print tls_main_tbss_2" ".* = 52"
+ gdb_test "print tls_main_tdata_1" ".* = 53"
+ gdb_test "print tls_main_tdata_2" ".* = 54"
+
+ set cond { $n == 1 || $n == 3 || $n == 4}
+ foreach n {1 3 4 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}51" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}52" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}53" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}54" $cond
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-7"]
+ gdb_continue_to_breakpoint "main-breakpoint-7"
+
+ # lib2 and lib3 are loaded; lib1 and lib4 are not.
+
+ with_test_prefix "at main-breakpoint-7" {
+ gdb_test "print tls_main_tbss_1" ".* = 61"
+ gdb_test "print tls_main_tbss_2" ".* = 62"
+ gdb_test "print tls_main_tdata_1" ".* = 63"
+ gdb_test "print tls_main_tdata_2" ".* = 64"
+
+ set cond { $n == 2 || $n == 3 }
+ foreach n {2 3 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}61" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}62" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}63" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}64" $cond
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-8"]
+ gdb_continue_to_breakpoint "main-breakpoint-8"
+
+ # lib1, lib2, lib3, and lib4 are all loaded.
+
+ with_test_prefix "at main-breakpoint-8" {
+ gdb_test "print tls_main_tbss_1" ".* = 71"
+ gdb_test "print tls_main_tbss_2" ".* = 72"
+ gdb_test "print tls_main_tdata_1" ".* = 73"
+ gdb_test "print tls_main_tdata_2" ".* = 74"
+
+ foreach n {1 2 3 4 10 11} {
+ gdb_test "print tls_lib${n}_tbss_1" ".* = ${n}71"
+ gdb_test "print tls_lib${n}_tbss_2" ".* = ${n}72"
+ gdb_test "print tls_lib${n}_tdata_1" ".* = ${n}73"
+ gdb_test "print tls_lib${n}_tdata_2" ".* = ${n}74"
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-9"]
+ gdb_continue_to_breakpoint "main-breakpoint-9"
+
+ # lib2 is loaded; lib1, lib3, and lib4 are not.
+
+ with_test_prefix "at main-breakpoint-9" {
+ gdb_test "print tls_main_tbss_1" ".* = 81"
+ gdb_test "print tls_main_tbss_2" ".* = 82"
+ gdb_test "print tls_main_tdata_1" ".* = 83"
+ gdb_test "print tls_main_tdata_2" ".* = 84"
+
+ foreach n {2 10 11} {
+ gdb_test "print tls_lib${n}_tbss_1" ".* = ${n}81"
+ gdb_test "print tls_lib${n}_tbss_2" ".* = ${n}82"
+ gdb_test "print tls_lib${n}_tdata_1" ".* = ${n}83"
+ gdb_test "print tls_lib${n}_tdata_2" ".* = ${n}84"
+ }
+ }
+
+ gdb_breakpoint [gdb_get_line_number "main-breakpoint-10"]
+ gdb_continue_to_breakpoint "main-breakpoint-10"
+
+ # lib3 and lib4 are loaded; lib1 and lib2 are not.
+
+ with_test_prefix "at main-breakpoint-10" {
+ gdb_test "print tls_main_tbss_1" ".* = 91"
+ gdb_test "print tls_main_tbss_2" ".* = 92"
+ gdb_test "print tls_main_tdata_1" ".* = 93"
+ gdb_test "print tls_main_tdata_2" ".* = 94"
+
+ set cond { $n == 3 || $n == 4 }
+ foreach n {3 4 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}91" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}92" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}93" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}94" $cond
+ }
+ }
+
+ # gdb_interact
+
+ set corefile ${::binfile}.core
+ set core_supported 0
+ if { ![is_remote host] } {
+ set core_supported [gdb_gcore_cmd $corefile "save corefile"]
+ }
+
+ # Finish test early if no core file was made.
+ if !$core_supported {
+ return
+ }
+
+ clean_restart $::binfile
+
+ set core_loaded [gdb_core_cmd $corefile "load corefile"]
+ if { $core_loaded == -1 } {
+ return
+ }
+
+ with_test_prefix "core file" {
+ if $force_internal_tls {
+ gdb_test_no_output "maint set force-internal-tls-address-lookup on"
+ }
+
+ gdb_test "print tls_main_tbss_1" ".* = 91"
+ gdb_test "print tls_main_tbss_2" ".* = 92"
+ gdb_test "print tls_main_tdata_1" ".* = 93"
+ gdb_test "print tls_main_tdata_2" ".* = 94"
+
+ set cond { $n == 3 || $n == 4 }
+ foreach n {3 4 10 11} {
+ gdb_test_with_xfail "print tls_lib${n}_tbss_1" ".* = ${n}91" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tbss_2" ".* = ${n}92" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_1" ".* = ${n}93" $cond
+ gdb_test_with_xfail "print tls_lib${n}_tdata_2" ".* = ${n}94" $cond
+ }
+ }
+}
+
+# Build shared objects for dlopen:
+if { [gdb_compile_shlib $libsrc $lib1obj [list debug additional_flags=-DN=1]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $libsrc $lib2obj [list debug additional_flags=-DN=2]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $libsrc $lib3obj [list debug additional_flags=-DN=3]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $libsrc $lib4obj [list debug additional_flags=-DN=4]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+
+# Build shared objects to link against main program:
+if { [gdb_compile_shlib $libsrc $lib10obj [list debug additional_flags=-DN=10]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+if { [gdb_compile_shlib $libsrc $lib11obj [list debug additional_flags=-DN=11]] != "" } {
+ untested "failed to compile shared object"
+ return -1
+}
+
+# Use gdb_compile_pthreads to build and link the main program for
+# testing. It's also possible to run the tests using plain old
+# gdb_compile, but this adds complexity with setting up additional
+# KFAILs. (When run using GLIBC versions earlier than 2.34, a program
+# that's not dynamically linked against libpthread will lack a working
+# libthread_db, and, therefore, won't be able to access thread local
+# storage without GDB-internal TLS support. Additional complications
+# arise from when testing on x86_64 with -m32, which tends to work
+# okay on GLIBC 2.34 and newer, but not older versions. It gets messy
+# to properly sort out all of these cases.)
+#
+# This test was originally written to do it both ways, i.e. with both
+# both gdb_compile and gdb_compile_pthreads, but the point of this
+# test is to check that the link map address to TLS module id mapping
+# code works correctly in programs which use lots of dlopen and
+# dlclose calls in various orders - and that can be done using just
+# gdb_compile_pthreads.
+
+if { [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable \
+ [list debug shlib_load \
+ shlib=${lib10obj} \
+ shlib=${lib11obj} \
+ additional_flags=-DOBJ1=\"${lib1obj}\" \
+ additional_flags=-DOBJ2=\"${lib2obj}\" \
+ additional_flags=-DOBJ3=\"${lib3obj}\" \
+ additional_flags=-DOBJ4=\"${lib4obj}\" \
+ ]] != "" } {
+ untested "failed to compile"
+} else {
+ foreach_with_prefix force_internal_tls $internal_tls_iters {
+ do_tests $force_internal_tls
+ }
+}
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v6 11/11] Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (9 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 10/11] New test - gdb.base/tls-dlobj.exp Kevin Buettner
@ 2025-04-04 23:37 ` Kevin Buettner
2025-04-18 18:36 ` [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
11 siblings, 0 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-04 23:37 UTC (permalink / raw)
To: gdb-patches; +Cc: Kevin Buettner
---
gdb/NEWS | 20 ++++++++++++++++++
gdb/doc/gdb.texinfo | 50 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 70 insertions(+)
diff --git a/gdb/NEWS b/gdb/NEWS
index 6a557bb4af9..8d6bc4f287b 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -56,6 +56,26 @@ info sharedlibrary
command are now for the full memory range allocated to the shared
library.
+* GDB-internal Thread Local Storage (TLS) support
+
+ ** Linux targets for the x86_64, aarch64, ppc64, s390x, and riscv
+ architectures now have GDB-internal support for TLS address
+ lookup in addition to that traditionally provided by the
+ libthread_db library. This internal support works for programs
+ linked against either the GLIBC or MUSL C libraries. For
+ programs linked against MUSL, this new internal support provides
+ new debug functionality, allowing access to TLS variables, due to
+ the fact that MUSL does not implement the libthread_db library.
+ Internal TLS support is also useful in cross-debugging
+ situations, debugging statically linked binaries, and debugging
+ programs linked against GLIBC 2.33 and earlier, but which are not
+ linked against libpthread.
+
+ ** The command 'maint set force-internal-tls-address-lookup on' may
+ be used to force the internal TLS lookup mechanisms to be used.
+ Otherwise, TLS lookup via libthread_db will still be preferred,
+ when available.
+
* Python API
** New class gdb.Color for dealing with colors.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index e034ac53295..257a7c60ec3 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -4090,6 +4090,56 @@ When @samp{on} @value{GDBN} will print additional messages when
threads are created and deleted.
@end table
+@cindex thread local storage
+@cindex @acronym{TLS}
+For some debugging targets, @value{GDBN} has support for accessing
+variables that reside in Thread Local Storage (@acronym{TLS}).
+@acronym{TLS} variables are similar to global variables, except that
+each thread has its own copy of the variable. While often used in
+multi-threaded programs, @acronym{TLS} variables can also be used in
+programs without threads. The C library variable @var{errno} is,
+perhaps, the most prominent example of a @acronym{TLS} variable that
+is frequently used in non-threaded programs. For targets where
+@value{GDBN} does not have good @acronym{TLS} support, printing or
+changing the value of @var{errno} might not be directly possible.
+
+@sc{gnu}/Linux and FreeBSD targets have support for accessing
+@acronym{TLS} variables. On @sc{gnu}/Linux, the helper library,
+@code{libthread_db}, is used to help resolve the addresses of
+@acronym{TLS} variables. Some FreeBSD and some @sc{gnu}/Linux targets
+also have @value{GDBN}-internal @acronym{TLS} resolution code.
+@sc{gnu}/Linux targets will attempt to use the @acronym{TLS} address
+lookup functionality provided by @code{libthread_db}, but will fall
+back to using its internal @acronym{TLS} support when
+@code{libthread_db} is not available. This can happen in
+cross-debugging scenarios or when debugging programs that are linked
+in such a way that @code{libthread_db} support is unavailable -- this
+includes statically linked programs, linking against @acronym{GLIBC}
+versions earlier than 2.34, but not with @code{libpthread}, and use of
+other (non-@acronym{GLIBC}) C libraries.
+
+@table @code
+@kindex maint set force-internal-tls-address-lookup
+@kindex maint show force-internal-tls-address-lookup
+@cindex internal @acronym{TLS} address lookup
+@item maint set force-internal-tls-address-lookup
+@itemx maint show force-internal-tls-address-lookup
+Turns on or off forced use of @value{GDBN}-internal @acronym{TLS}
+address lookup code. Use @code{on} to enable and @code{off} to
+disable. The default for this setting is @code{off}.
+
+When disabled, @value{GDBN} will attempt to use a helper
+@code{libthread_db} library if possible, but will fall back to use of
+its own internal @acronym{TLS} address lookup mechanisms if necessary.
+
+When enabled, @value{GDBN} will only use @value{GDBN}'s internal
+@acronym{TLS} address lookup mechanisms, if they exist.
+
+This command is only available for @sc{gnu}/Linux targets. Its
+primary use is for testing -- certain tests in the @value{GDBN} test
+suite use this command to force use of internal TLS address lookup.
+@end table
+
@node Forks
@section Debugging Forks
--
2.48.1
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets
2025-04-04 23:37 [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
` (10 preceding siblings ...)
2025-04-04 23:37 ` [PATCH v6 11/11] Add TLS NEWS entry and document 'set force-internal-tls-address-lookup' command Kevin Buettner
@ 2025-04-18 18:36 ` Kevin Buettner
2025-04-22 15:03 ` Tom Tromey
2025-04-23 14:12 ` Luis Machado
11 siblings, 2 replies; 17+ messages in thread
From: Kevin Buettner @ 2025-04-18 18:36 UTC (permalink / raw)
To: gdb-patches
I plan on pushing this series late next week (on or around April 25)
unless there are objections.
Kevin
On Fri, 4 Apr 2025 16:37:31 -0700
Kevin Buettner <kevinb@redhat.com> wrote:
> This series of commits adds internal TLS lookup support to GDB for the
> following Linux target architectures: x86_64, aarch64, ppc64, s390x,
> and riscv. When available, libthread_db support for TLS lookup is
> still preferred/used since it should be more accurate. This means
> that existing TLS support will still work as it did before - this new
> TLS support will only be used when libthread_db TLS support is not
> available. That said, it is possible to force internal TLS support to
> be used via a new maintenance command.
>
> Three of the commits in this series provide knowledge about how to
> translate link map addresses to module ids and how to traverse various
> TLS data structures. The latter problem is broken into two parts,
> one which applies to all Linux architectures, and a second which
> adds architecture specific knowledge about TLS data structures.
>
> Translating link map addresses to module ids is tricky. In theory,
> the module id is available in the link map data structure, but it's
> not part of the ABI. I ended up implementing two mechanisms for
> doing this mapping, one for MUSL, and one for GLIBC. For both of
> these, I think the method that I used is less fragile than attempting
> to use an offset to the module id field for current versions of these
> libraries.
>
> Traversing TLS data structures starts with obtaining the value of the
> thread register (or registers for S390X), then finding the field
> containing the DTV (dynamic thread vector) address within the TCB
> (thread control block), then using the module id as an index into the
> DTV in order to obtain the TLS block. For some architectures, the
> MUSL C library requires that a final adjustment be made to obtain the
> actual address of the TLS block.
>
> This patch set also shows how internal TLS support might be added for
> i386, however, due to problems with accessing the gsbase register, it
> doesn't work, so the commit which adds this potential support is then
> immediately deleted in the next commit. The point of doing this is to
> make it available in our git repo to anyone who wishes to work on i386
> support. IMO, it's not worth doing without also doing corresponding
> ptrace work in the kernel. I think this would have been worth doing
> back in the i386 heyday, but is not worth doing now. That said,
> should anyone wish to look into it, the commit showing how to do it
> will be in our repo as well as on the mailing list.
>
> The details for traversing the TLS data structures differ not only
> between architectures, but also depends upon the C library with which
> the executable being debugged has been linked. The internal TLS
> support in this series is known to work with GLIBC versions 2.27 thru
> 2.41.9000 and MUSL versions 1.1.24, 1.2.3 and 1.2.5. For MUSL, the
> support provided by this series provides new debugging functionality
> that didn't exist before - it will now be possible to examine TLS
> variables in programs linked against MUSL. (It didn't work before
> due to MUSL not implementing the libthread_db library.)
>
> I've done regression testing on recent Fedora versions for all five
> architectures. Bugs were found and fixed during that testing.
>
> Once that was done, I did even more testing, using a limited number of
> tests. These include the new tests that I've added, plus those tests
> with which regression testing identified some problems. The list is:
>
> TESTS="gdb.base/tls-dlobj.exp gdb.base/tls-nothreads.exp \
> gdb.base/tls-multiobj.exp gdb.threads/tls.exp \
> gdb.server/no-thread-db.exp"
>
> I tested using targets:
>
> unix, native-gdbserver, native-extended-gdbserver,
>
> and, for x86_64 targets, I also tested with 32-bit variants:
>
> unix/-m32, native-gdbserver/-m32, and native-extended-gdbserver/-m32
>
> I also tested with no CC_FOR_TARGET (which defaults to gcc),
> CC_FOR_TARGET=musl-gcc, and CC_FOR_TARGET=clang. On Fedora, using
> CC_FOR_TARGET=musl-gcc causes the program and libraries to be compiled
> with gcc, but linked against the MUSL C library. I didn't use this
> option on non-Fedora machines, though my Void linux testing tested
> using the MUSL library since that's what's installed in that test
> environment.
>
> I also ran additional tests using check-read1 for combos with no
> CC_FOR_TARGET.
>
> Using all sensible combinations of the above, I tested on 13 machines / 5
> architectures:
>
> x86_64 / Fedora 28 / glibc-2.27
> x86_64 / Fedora 34 / glibc-2.33 / musl-libc-1.2.3
> x86_64 / Fedora 35 / glibc-2.34 / musl-libc-1.2.3
> x86_64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
> x86_64 / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
> x86_64 / rawhide (fc42) / glibc-2.40.9000 / musl-libc-1.2.5
> x86_64 / OpenSuse Leap 15.5 / glibc-2.31 / no musl
> x86_64 / Ubuntu 22.04 / glibc-2.35 / no musl
> x86_64 / void - 2024-03-14 / no glibc / musl 1.1.24
>
> aarch64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
> riscv / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
> ppc64le / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
> s390x / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>
> The point of testing old Fedora releases is to be able to test
> older glibc versions. In particular glibc-2.33 and earlier
> had pthread functionality split into libpthread.so while glibc-2.34
> and later place it into libc proper.
>
> All of the testing went well except on riscv and s390x with
> CC_FOR_TARGET=clang. That's six test runs total, and they each show
> 799 FAILs. The test results show that riscv mostly prints the wrong
> answer and that s390x shows output like "Cannot access memory at
> address 0x3fff8d494e8". But this happens regardless of whether
> internal TLS support or libthread_db support is used. I think it's
> likely that it's a clang bug of which I can do nothing about (aside
> from filing a bug report).
>
> The v2 series fixed some problems in the gdb.base/tls-dlobj.exp test
> found by the Linaro regression tester, tweaked a comment in
> aarch64-linux-tdep.c, included a discussion of what TLS is in the
> documentation patch, and renamed 'set force-internal-tls-address-lookup'
> to be a maintenance command. Thanks to Luis and Eli for their
> feedback on the v1 series. Thanks, too, to Linaro for regression
> tester feedback.
>
> The v3 series made corrections to the documentation, as requested by
> Eli.
>
> The v4 series fixed some other documentation nits.
>
> The v5 series moves the "target has registers" check and output of a
> suitable error message into target_translate_tls_address. In v4 and
> earlier, this error check was being performed at some of the call
> sites for target_translate_tls_address. The entire series has been
> retested as described above, though on a subset of targets. All
> five architectures (x86_64, aarch64, ppc64le, s390x, and riscv) have
> all been tested though. Additionally, testing has been done on
> machines with recent glibc versions in addition to a version of glibc
> which predates 2.34, specifically glibc-2.33.
>
> This v6 series addresses a problem found by Andrew Burgess: In his
> review of the v5 series, Andrew observed that not all Linux targets
> use SVR4 shared library support, and therefore can not depend on
> extern functions defined in solib-svr4.c to be available. One example
> is FR-V Linux which uses solib-frv.c in order to provide support for
> the FDPIC shared library ABI. I addressed this problem by moving
> non-architecture-specific TLS code out of linux-tdep.c (which is used
> by all Linux targets) into a new file named svr4-tls-tdep.c. In order
> to make sure that svr4-tls-tdep.o is linked into the correct targets
> (when not doing a --enable-targets=all configuration), svr4-tls-tdep.o
> has been added to the target_obs definition in gdb/configure.tgt for
> the various target patterns which should have internal TLS lookup
> support. This change, which moves the generic internal TLS support
> out of a linux specific file into a new file, makes this TLS support
> infrastructure available to other targets which use SVR4 shared libary
> support, whether they're Linux targets or not. For example, GDB's
> GNU/Hurd support or perhaps BSD support could now use these
> mechanisms. (For the latter, I suspect that we'd need to teach it
> about BSD's libc.)
>
> Kevin Buettner (11):
> Don't attempt to find TLS address when target has no registers
> Allow TLS access to work in gdb.server/no-thread-db.exp
> Track and fetch TLS module ids for MUSL and GLIBC
> Implement internal TLS address lookup for select Linux targets
> Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
> Internal, but disabled, TLS support for i386
> Delete disabled i386 internal TLS support
> New test - gdb.base/tls-nothreads.exp
> New test - gdb.base/tls-multiobj.exp
> New test - gdb.base/tls-dlobj.exp
> Add TLS NEWS entry and document 'set
> force-internal-tls-address-lookup' command
>
> gdb/Makefile.in | 3 +
> gdb/NEWS | 20 ++
> gdb/aarch64-linux-tdep.c | 56 ++++
> gdb/amd64-linux-tdep.c | 38 +++
> gdb/configure.tgt | 11 +-
> gdb/doc/gdb.texinfo | 50 +++
> gdb/findvar.c | 3 +-
> gdb/linux-tdep.c | 1 +
> gdb/minsyms.c | 3 +-
> gdb/ppc-linux-tdep.c | 63 ++++
> gdb/riscv-linux-tdep.c | 79 +++++
> gdb/s390-linux-tdep.c | 44 +++
> gdb/solib-svr4.c | 207 +++++++++++-
> gdb/solib-svr4.h | 12 +
> gdb/svr4-tls-tdep.c | 256 +++++++++++++++
> gdb/svr4-tls-tdep.h | 59 ++++
> gdb/target.c | 16 +-
> gdb/target.h | 8 +-
> gdb/testsuite/gdb.base/tls-common.exp.tcl | 50 +++
> gdb/testsuite/gdb.base/tls-dlobj-lib.c | 87 +++++
> gdb/testsuite/gdb.base/tls-dlobj.c | 311 ++++++++++++++++++
> gdb/testsuite/gdb.base/tls-dlobj.exp | 378 ++++++++++++++++++++++
> gdb/testsuite/gdb.base/tls-multiobj.c | 89 +++++
> gdb/testsuite/gdb.base/tls-multiobj.exp | 230 +++++++++++++
> gdb/testsuite/gdb.base/tls-multiobj1.c | 26 ++
> gdb/testsuite/gdb.base/tls-multiobj2.c | 26 ++
> gdb/testsuite/gdb.base/tls-multiobj3.c | 26 ++
> gdb/testsuite/gdb.base/tls-nothreads.c | 57 ++++
> gdb/testsuite/gdb.base/tls-nothreads.exp | 248 ++++++++++++++
> gdb/testsuite/gdb.server/no-thread-db.exp | 4 +-
> gdb/testsuite/gdb.threads/tls.exp | 2 +-
> 31 files changed, 2446 insertions(+), 17 deletions(-)
> create mode 100644 gdb/svr4-tls-tdep.c
> create mode 100644 gdb/svr4-tls-tdep.h
> create mode 100644 gdb/testsuite/gdb.base/tls-common.exp.tcl
> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj-lib.c
> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.c
> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.exp
> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.c
> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.exp
> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj1.c
> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj2.c
> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj3.c
> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.c
> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.exp
>
> --
> 2.48.1
>
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets
2025-04-18 18:36 ` [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
@ 2025-04-22 15:03 ` Tom Tromey
2025-04-23 14:12 ` Luis Machado
1 sibling, 0 replies; 17+ messages in thread
From: Tom Tromey @ 2025-04-22 15:03 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
Kevin> I plan on pushing this series late next week (on or around April 25)
Kevin> unless there are objections.
I didn't read it closely but FWIW I think you should go ahead.
Tom
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets
2025-04-18 18:36 ` [PATCH v6 00/11] GDB-internal TLS support for Linux targets Kevin Buettner
2025-04-22 15:03 ` Tom Tromey
@ 2025-04-23 14:12 ` Luis Machado
2025-04-23 22:14 ` Kevin Buettner
1 sibling, 1 reply; 17+ messages in thread
From: Luis Machado @ 2025-04-23 14:12 UTC (permalink / raw)
To: Kevin Buettner, gdb-patches
On 4/18/25 19:36, Kevin Buettner wrote:
> I plan on pushing this series late next week (on or around April 25)
> unless there are objections.
>
> Kevin
>
> On Fri, 4 Apr 2025 16:37:31 -0700
> Kevin Buettner <kevinb@redhat.com> wrote:
>
>> This series of commits adds internal TLS lookup support to GDB for the
>> following Linux target architectures: x86_64, aarch64, ppc64, s390x,
>> and riscv. When available, libthread_db support for TLS lookup is
>> still preferred/used since it should be more accurate. This means
>> that existing TLS support will still work as it did before - this new
>> TLS support will only be used when libthread_db TLS support is not
>> available. That said, it is possible to force internal TLS support to
>> be used via a new maintenance command.
>>
>> Three of the commits in this series provide knowledge about how to
>> translate link map addresses to module ids and how to traverse various
>> TLS data structures. The latter problem is broken into two parts,
>> one which applies to all Linux architectures, and a second which
>> adds architecture specific knowledge about TLS data structures.
>>
>> Translating link map addresses to module ids is tricky. In theory,
>> the module id is available in the link map data structure, but it's
>> not part of the ABI. I ended up implementing two mechanisms for
>> doing this mapping, one for MUSL, and one for GLIBC. For both of
>> these, I think the method that I used is less fragile than attempting
>> to use an offset to the module id field for current versions of these
>> libraries.
>>
>> Traversing TLS data structures starts with obtaining the value of the
>> thread register (or registers for S390X), then finding the field
>> containing the DTV (dynamic thread vector) address within the TCB
>> (thread control block), then using the module id as an index into the
>> DTV in order to obtain the TLS block. For some architectures, the
>> MUSL C library requires that a final adjustment be made to obtain the
>> actual address of the TLS block.
>>
>> This patch set also shows how internal TLS support might be added for
>> i386, however, due to problems with accessing the gsbase register, it
>> doesn't work, so the commit which adds this potential support is then
>> immediately deleted in the next commit. The point of doing this is to
>> make it available in our git repo to anyone who wishes to work on i386
>> support. IMO, it's not worth doing without also doing corresponding
>> ptrace work in the kernel. I think this would have been worth doing
>> back in the i386 heyday, but is not worth doing now. That said,
>> should anyone wish to look into it, the commit showing how to do it
>> will be in our repo as well as on the mailing list.
>>
>> The details for traversing the TLS data structures differ not only
>> between architectures, but also depends upon the C library with which
>> the executable being debugged has been linked. The internal TLS
>> support in this series is known to work with GLIBC versions 2.27 thru
>> 2.41.9000 and MUSL versions 1.1.24, 1.2.3 and 1.2.5. For MUSL, the
>> support provided by this series provides new debugging functionality
>> that didn't exist before - it will now be possible to examine TLS
>> variables in programs linked against MUSL. (It didn't work before
>> due to MUSL not implementing the libthread_db library.)
>>
>> I've done regression testing on recent Fedora versions for all five
>> architectures. Bugs were found and fixed during that testing.
>>
>> Once that was done, I did even more testing, using a limited number of
>> tests. These include the new tests that I've added, plus those tests
>> with which regression testing identified some problems. The list is:
>>
>> TESTS="gdb.base/tls-dlobj.exp gdb.base/tls-nothreads.exp \
>> gdb.base/tls-multiobj.exp gdb.threads/tls.exp \
>> gdb.server/no-thread-db.exp"
>>
>> I tested using targets:
>>
>> unix, native-gdbserver, native-extended-gdbserver,
>>
>> and, for x86_64 targets, I also tested with 32-bit variants:
>>
>> unix/-m32, native-gdbserver/-m32, and native-extended-gdbserver/-m32
>>
>> I also tested with no CC_FOR_TARGET (which defaults to gcc),
>> CC_FOR_TARGET=musl-gcc, and CC_FOR_TARGET=clang. On Fedora, using
>> CC_FOR_TARGET=musl-gcc causes the program and libraries to be compiled
>> with gcc, but linked against the MUSL C library. I didn't use this
>> option on non-Fedora machines, though my Void linux testing tested
>> using the MUSL library since that's what's installed in that test
>> environment.
>>
>> I also ran additional tests using check-read1 for combos with no
>> CC_FOR_TARGET.
>>
>> Using all sensible combinations of the above, I tested on 13 machines / 5
>> architectures:
>>
>> x86_64 / Fedora 28 / glibc-2.27
>> x86_64 / Fedora 34 / glibc-2.33 / musl-libc-1.2.3
>> x86_64 / Fedora 35 / glibc-2.34 / musl-libc-1.2.3
>> x86_64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>> x86_64 / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
>> x86_64 / rawhide (fc42) / glibc-2.40.9000 / musl-libc-1.2.5
>> x86_64 / OpenSuse Leap 15.5 / glibc-2.31 / no musl
>> x86_64 / Ubuntu 22.04 / glibc-2.35 / no musl
>> x86_64 / void - 2024-03-14 / no glibc / musl 1.1.24
>>
>> aarch64 / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>> riscv / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>> ppc64le / Fedora 41 / glibc-2.40 / musl-libc-1.2.5
>> s390x / Fedora 40 / glibc-2.39 / musl-libc-1.2.5
>>
>> The point of testing old Fedora releases is to be able to test
>> older glibc versions. In particular glibc-2.33 and earlier
>> had pthread functionality split into libpthread.so while glibc-2.34
>> and later place it into libc proper.
>>
>> All of the testing went well except on riscv and s390x with
>> CC_FOR_TARGET=clang. That's six test runs total, and they each show
>> 799 FAILs. The test results show that riscv mostly prints the wrong
>> answer and that s390x shows output like "Cannot access memory at
>> address 0x3fff8d494e8". But this happens regardless of whether
>> internal TLS support or libthread_db support is used. I think it's
>> likely that it's a clang bug of which I can do nothing about (aside
>> from filing a bug report).
>>
>> The v2 series fixed some problems in the gdb.base/tls-dlobj.exp test
>> found by the Linaro regression tester, tweaked a comment in
>> aarch64-linux-tdep.c, included a discussion of what TLS is in the
>> documentation patch, and renamed 'set force-internal-tls-address-lookup'
>> to be a maintenance command. Thanks to Luis and Eli for their
>> feedback on the v1 series. Thanks, too, to Linaro for regression
>> tester feedback.
>>
>> The v3 series made corrections to the documentation, as requested by
>> Eli.
>>
>> The v4 series fixed some other documentation nits.
>>
>> The v5 series moves the "target has registers" check and output of a
>> suitable error message into target_translate_tls_address. In v4 and
>> earlier, this error check was being performed at some of the call
>> sites for target_translate_tls_address. The entire series has been
>> retested as described above, though on a subset of targets. All
>> five architectures (x86_64, aarch64, ppc64le, s390x, and riscv) have
>> all been tested though. Additionally, testing has been done on
>> machines with recent glibc versions in addition to a version of glibc
>> which predates 2.34, specifically glibc-2.33.
>>
>> This v6 series addresses a problem found by Andrew Burgess: In his
>> review of the v5 series, Andrew observed that not all Linux targets
>> use SVR4 shared library support, and therefore can not depend on
>> extern functions defined in solib-svr4.c to be available. One example
>> is FR-V Linux which uses solib-frv.c in order to provide support for
>> the FDPIC shared library ABI. I addressed this problem by moving
>> non-architecture-specific TLS code out of linux-tdep.c (which is used
>> by all Linux targets) into a new file named svr4-tls-tdep.c. In order
>> to make sure that svr4-tls-tdep.o is linked into the correct targets
>> (when not doing a --enable-targets=all configuration), svr4-tls-tdep.o
>> has been added to the target_obs definition in gdb/configure.tgt for
>> the various target patterns which should have internal TLS lookup
>> support. This change, which moves the generic internal TLS support
>> out of a linux specific file into a new file, makes this TLS support
>> infrastructure available to other targets which use SVR4 shared libary
>> support, whether they're Linux targets or not. For example, GDB's
>> GNU/Hurd support or perhaps BSD support could now use these
>> mechanisms. (For the latter, I suspect that we'd need to teach it
>> about BSD's libc.)
>>
>> Kevin Buettner (11):
>> Don't attempt to find TLS address when target has no registers
>> Allow TLS access to work in gdb.server/no-thread-db.exp
>> Track and fetch TLS module ids for MUSL and GLIBC
>> Implement internal TLS address lookup for select Linux targets
>> Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
>> Internal, but disabled, TLS support for i386
>> Delete disabled i386 internal TLS support
>> New test - gdb.base/tls-nothreads.exp
>> New test - gdb.base/tls-multiobj.exp
>> New test - gdb.base/tls-dlobj.exp
>> Add TLS NEWS entry and document 'set
>> force-internal-tls-address-lookup' command
>>
>> gdb/Makefile.in | 3 +
>> gdb/NEWS | 20 ++
>> gdb/aarch64-linux-tdep.c | 56 ++++
>> gdb/amd64-linux-tdep.c | 38 +++
>> gdb/configure.tgt | 11 +-
>> gdb/doc/gdb.texinfo | 50 +++
>> gdb/findvar.c | 3 +-
>> gdb/linux-tdep.c | 1 +
>> gdb/minsyms.c | 3 +-
>> gdb/ppc-linux-tdep.c | 63 ++++
>> gdb/riscv-linux-tdep.c | 79 +++++
>> gdb/s390-linux-tdep.c | 44 +++
>> gdb/solib-svr4.c | 207 +++++++++++-
>> gdb/solib-svr4.h | 12 +
>> gdb/svr4-tls-tdep.c | 256 +++++++++++++++
>> gdb/svr4-tls-tdep.h | 59 ++++
>> gdb/target.c | 16 +-
>> gdb/target.h | 8 +-
>> gdb/testsuite/gdb.base/tls-common.exp.tcl | 50 +++
>> gdb/testsuite/gdb.base/tls-dlobj-lib.c | 87 +++++
>> gdb/testsuite/gdb.base/tls-dlobj.c | 311 ++++++++++++++++++
>> gdb/testsuite/gdb.base/tls-dlobj.exp | 378 ++++++++++++++++++++++
>> gdb/testsuite/gdb.base/tls-multiobj.c | 89 +++++
>> gdb/testsuite/gdb.base/tls-multiobj.exp | 230 +++++++++++++
>> gdb/testsuite/gdb.base/tls-multiobj1.c | 26 ++
>> gdb/testsuite/gdb.base/tls-multiobj2.c | 26 ++
>> gdb/testsuite/gdb.base/tls-multiobj3.c | 26 ++
>> gdb/testsuite/gdb.base/tls-nothreads.c | 57 ++++
>> gdb/testsuite/gdb.base/tls-nothreads.exp | 248 ++++++++++++++
>> gdb/testsuite/gdb.server/no-thread-db.exp | 4 +-
>> gdb/testsuite/gdb.threads/tls.exp | 2 +-
>> 31 files changed, 2446 insertions(+), 17 deletions(-)
>> create mode 100644 gdb/svr4-tls-tdep.c
>> create mode 100644 gdb/svr4-tls-tdep.h
>> create mode 100644 gdb/testsuite/gdb.base/tls-common.exp.tcl
>> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj-lib.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-dlobj.exp
>> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj.exp
>> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj1.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj2.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-multiobj3.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.c
>> create mode 100644 gdb/testsuite/gdb.base/tls-nothreads.exp
>>
>> --
>> 2.48.1
>>
>
Do you have an updated series that applies cleanly on master? Looks
like there are some conflicts at the moment.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets
2025-04-23 14:12 ` Luis Machado
@ 2025-04-23 22:14 ` Kevin Buettner
2025-04-24 6:34 ` Luis Machado
0 siblings, 1 reply; 17+ messages in thread
From: Kevin Buettner @ 2025-04-23 22:14 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb-patches
On Wed, 23 Apr 2025 15:12:01 +0100
Luis Machado <luis.machado@arm.com> wrote:
> Do you have an updated series that applies cleanly on master? Looks
> like there are some conflicts at the moment.
So it turned out that were some riscv conflicts and also some
conflicts introduced from the linker namespace work.
I've done a rebase and am building / testing now. I hope to post an
updated series later today (Apr 23). I'll probably delay pushing the
series until Friday, May 2 in order to give you and others a chance
to try it out.
Kevin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v6 00/11] GDB-internal TLS support for Linux targets
2025-04-23 22:14 ` Kevin Buettner
@ 2025-04-24 6:34 ` Luis Machado
0 siblings, 0 replies; 17+ messages in thread
From: Luis Machado @ 2025-04-24 6:34 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
On 4/23/25 23:14, Kevin Buettner wrote:
> On Wed, 23 Apr 2025 15:12:01 +0100
> Luis Machado <luis.machado@arm.com> wrote:
>
>> Do you have an updated series that applies cleanly on master? Looks
>> like there are some conflicts at the moment.
>
> So it turned out that were some riscv conflicts and also some
> conflicts introduced from the linker namespace work.
>
> I've done a rebase and am building / testing now. I hope to post an
> updated series later today (Apr 23). I'll probably delay pushing the
> series until Friday, May 2 in order to give you and others a chance
> to try it out.
>
> Kevin
>
Thanks. I see it now. I'll give it a spin on my end and will report back.
^ permalink raw reply [flat|nested] 17+ messages in thread