From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Gary Funck <gary@intrepid.com>
Cc: Vinay Sridhar <vinay@linux.vnet.ibm.com>,
gdb-patches@sources.redhat.com,
Daniel Jacobowitz <drow@false.org>,
luisgpm@linux.vnet.ibm.com, uweigand@de.ibm.com
Subject: Re: [patch] Accessing tls variables across files causes a bug
Date: Mon, 01 Dec 2008 14:15:00 -0000 [thread overview]
Message-ID: <20081201141408.GA10447@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20081126204316.GA11366@host0.dyn.jankratochvil.net>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
Hi,
(re)patched. GDB misses getters to do it universally.
Testsuite addition, no regressions (x86_64-unknown-linux-gnu):
+PASS: gdb.threads/tls.exp: p a_thread_local
+PASS: gdb.threads/tls.exp: p file2_thread_local
+PASS: gdb.threads/tls.exp: info address file2_thread_local
+PASS: gdb.threads/tls.exp: p a_thread_local second time
+PASS: gdb.threads/tls.exp: info address a_thread_local
Regards,
Jan
[-- Attachment #2: gdb-extern-tls.patch --]
[-- Type: text/plain, Size: 6500 bytes --]
2008-11-29 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix resolving external references to TLS variables.
* findvar.c: Include `objfiles.h'.
(read_var_value <LOC_UNRESOLVED>): New variable `obj_section'. Handle
SEC_THREAD_LOCAL variables.
* printcmd.c (address_info <LOC_UNRESOLVED>): New variable
`obj_section'. Handle SEC_THREAD_LOCAL variables.
2008-11-29 Jan Kratochvil <jan.kratochvil@redhat.com>
Test resolving external references to TLS variables.
* gdb.threads/tls.exp: New tests to examine A_THREAD_LOCAL and
FILE2_THREAD_LOCAL.
(testfile2, srcfile2): New variables.
* gdb.threads/tls.c (file2_thread_local)
(function_referencing_file2_thread_local): New.
* gdb.threads/tls2.c: New file.
--- gdb/findvar.c 5 Sep 2008 11:37:17 -0000 1.118
+++ gdb/findvar.c 30 Nov 2008 21:10:02 -0000
@@ -34,6 +34,7 @@
#include "regcache.h"
#include "user-regs.h"
#include "block.h"
+#include "objfiles.h"
/* Basic byte-swapping routines. GDB has needed these for a long time...
All extract a target-format integer at ADDR which is LEN bytes long. */
@@ -536,6 +537,7 @@ read_var_value (struct symbol *var, stru
case LOC_UNRESOLVED:
{
struct minimal_symbol *msym;
+ struct obj_section *obj_section;
msym = lookup_minimal_symbol (SYMBOL_LINKAGE_NAME (var), NULL, NULL);
if (msym == NULL)
@@ -545,6 +547,12 @@ read_var_value (struct symbol *var, stru
SYMBOL_OBJ_SECTION (msym));
else
addr = SYMBOL_VALUE_ADDRESS (msym);
+
+ /* SYMBOL_VALUE_ADDRESS should return the translated address. */
+ obj_section = SYMBOL_OBJ_SECTION (msym);
+ if (obj_section
+ && (obj_section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0)
+ addr = target_translate_tls_address (obj_section->objfile, addr);
}
break;
--- gdb/printcmd.c 20 Nov 2008 16:13:11 -0000 1.138
+++ gdb/printcmd.c 30 Nov 2008 21:10:06 -0000
@@ -1234,6 +1234,7 @@ address_info (char *exp, int from_tty)
case LOC_UNRESOLVED:
{
struct minimal_symbol *msym;
+ struct obj_section *obj_section;
msym = lookup_minimal_symbol (SYMBOL_LINKAGE_NAME (sym), NULL, NULL);
if (msym == NULL)
@@ -1241,8 +1242,19 @@ address_info (char *exp, int from_tty)
else
{
section = SYMBOL_OBJ_SECTION (msym);
- printf_filtered (_("static storage at address "));
load_addr = SYMBOL_VALUE_ADDRESS (msym);
+
+ /* SYMBOL_VALUE_ADDRESS should return the translated address. */
+ if (section
+ && (section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0)
+ {
+ printf_filtered (_("a thread-local variable at offset %s "
+ "at final address "), paddr_nz (load_addr));
+ load_addr = target_translate_tls_address (section->objfile,
+ load_addr);
+ }
+ else
+ printf_filtered (_("static storage at address "));
fputs_filtered (paddress (load_addr), gdb_stdout);
if (section_is_overlay (section))
{
--- gdb/testsuite/gdb.threads/tls.c 29 Jul 2003 21:51:25 -0000 1.2
+++ gdb/testsuite/gdb.threads/tls.c 30 Nov 2008 21:10:09 -0000
@@ -20,6 +20,9 @@
__thread int a_thread_local;
__thread int another_thread_local;
+/* psymtabs->symtabs resolving check. */
+extern __thread int file2_thread_local;
+
/* Global variable just for info addr in gdb. */
int a_global;
@@ -119,6 +122,12 @@ void *spin( vp )
}
void
+function_referencing_file2_thread_local (void)
+{
+ file2_thread_local = file2_thread_local;
+}
+
+void
do_pass()
{
int i;
--- gdb/testsuite/gdb.threads/tls.exp 6 Aug 2008 12:52:08 -0000 1.9
+++ gdb/testsuite/gdb.threads/tls.exp 30 Nov 2008 21:10:09 -0000
@@ -15,7 +15,9 @@
# along with this program. If not, see <http://www.gnu.org/licenses/>. */
set testfile tls
+set testfile2 tls2
set srcfile ${testfile}.c
+set srcfile2 ${testfile2}.c
set binfile ${objdir}/${subdir}/${testfile}
if [istarget "*-*-linux"] then {
@@ -24,7 +26,7 @@ if [istarget "*-*-linux"] then {
set target_cflags ""
}
-if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug "incdir=${objdir}"]] != "" } {
+if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile} ${srcdir}/${subdir}/${srcfile2}" "${binfile}" executable [list debug "incdir=${objdir}"]] != "" } {
return -1
}
@@ -284,6 +286,20 @@ gdb_test "info address a_global" \
setup_kfail "gdb/1294" "*-*-*"
gdb_test "info address me" ".*me.*is a variable at offset.*" "info address me"
+
+# Test LOC_UNRESOLVED references resolving for `extern' TLS variables.
+
+gdb_test "p a_thread_local" " = \[0-9\]+"
+# Here it could crash with: Cannot access memory at address 0x0
+gdb_test "p file2_thread_local" " = \[0-9\]+"
+# Depending on the current lookup scope we may get two answers:
+# LOC_UNRESOLVED: Symbol "file2_thread_local" is a thread-local variable at offset 8 at final address 0x7ffff7fdb94c.
+# LOC_COMPUTED: Symbol "file2_thread_local" is a thread-local variable at offset 8 in the thread-local storage for `.../gdb.threads/tls'.
+gdb_test "info address file2_thread_local" "Symbol \"file2_thread_local\" is a thread-local variable.*"
+# Here it could also crash with: Cannot access memory at address 0x0
+gdb_test "p a_thread_local" " = \[0-9\]+" "p a_thread_local second time"
+gdb_test "info address a_thread_local" "Symbol \"a_thread_local\" is a thread-local variable.*"
+
# Done!
#
gdb_exit
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ gdb/testsuite/gdb.threads/tls2.c 30 Nov 2008 21:10:09 -0000
@@ -0,0 +1,28 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2008 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/>.
+
+ Please email any bugs, comments, and/or additions to this file to:
+ bug-gdb@prep.ai.mit.edu */
+
+extern __thread int a_thread_local;
+__thread int file2_thread_local;
+
+void
+function_referencing_a_thread_local (void)
+{
+ a_thread_local = a_thread_local;
+}
next prev parent reply other threads:[~2008-12-01 14:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 4:24 [Fwd: Re: [patch] Re: Accessing tls variables across files causes a bug] Vinay Sridhar
2008-11-27 15:01 ` [patch] Accessing tls variables across files causes a bug Gary Funck
2008-11-27 17:07 ` Jan Kratochvil
2008-12-01 14:15 ` Jan Kratochvil [this message]
2008-12-01 18:30 ` Ulrich Weigand
[not found] ` <20081201182931.GA18248@intrepid.com>
2008-12-01 21:54 ` Jan Kratochvil
2008-12-02 13:54 ` Ulrich Weigand
2008-12-02 14:53 ` Gary Funck
2008-12-02 15:13 ` Jan Kratochvil
2008-12-02 15:40 ` Gary Funck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081201141408.GA10447@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=drow@false.org \
--cc=gary@intrepid.com \
--cc=gdb-patches@sources.redhat.com \
--cc=luisgpm@linux.vnet.ibm.com \
--cc=uweigand@de.ibm.com \
--cc=vinay@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox