thread local storage (__thread) variables aren't working in gdb 6.5/6.6?

I can't find any confirmation of support or non-support of
thread
local storage on the web or in the gdb documentation. I
already tried
6.6 and it was the same problem. The test below seems to
confirm
non-support on my fedora core 6 (kernel 2.6.18) x86
distribution with
gdb 6.5. Please let me know if I am doing something wrong
for
debugging __thread global variables.

Thanks,
John


--- begin main.cpp ---
__thread int tlstest = 5;

int main()
{
	tlstest = 4; // line 5
	return 0;
}

--- begin Makefile ---
CXXFLAGS += -g
main : main.o

jbateslocalhost:~/samples/tls_test$ make
g++ -g   -c -o main.o main.cpp
cc   main.o   -o main
jbateslocalhost:~/samples/tls_test$ gdb main
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

(gdb) b main.cpp:5
Breakpoint 1 at 0x8048352: file main.cpp, line 5.
(gdb) run
Starting program: /home/jbates/samples/tls_test/main

Breakpoint 1, main () at main.cpp:5
5               tlstest = 4;
(gdb) p tlstest
Cannot access memory at address 0x0
(gdb)

On Tue, Jun 19, 2007 at 01:22:04PM -0700, John Bates wrote:
> I can't find any confirmation of support or non-support
of thread
> local storage on the web or in the gdb documentation. I
already tried
> 6.6 and it was the same problem. The test below seems
to confirm
> non-support on my fedora core 6 (kernel 2.6.18) x86
distribution with
> gdb 6.5. Please let me know if I am doing something
wrong for
> debugging __thread global variables.

So far, they are only supported if you are linked to
libpthread.  Jan
K. was working on this earlier.

-- 
Daniel Jacobowitz
CodeSourcery

On 6/19/07, Daniel Jacobowitz <drowfalse.org> wrote:
> On Tue, Jun 19, 2007 at 01:22:04PM -0700, John Bates
wrote:
> > I can't find any confirmation of support or
non-support of thread
> > local storage on the web or in the gdb
documentation. I already tried
> > 6.6 and it was the same problem. The test below
seems to confirm
> > non-support on my fedora core 6 (kernel 2.6.18)
x86 distribution with
> > gdb 6.5. Please let me know if I am doing
something wrong for
> > debugging __thread global variables.
>
> So far, they are only supported if you are linked to
libpthread.  Jan
> K. was working on this earlier.

I tried linking the program with -lpthread, if that's what
you meant,
and the same problem is occuring. Or do you mean linking gdb
with
pthread somehow?

Thanks,
John

On Tue, Jun 19, 2007 at 01:56:51PM -0700, John Bates wrote:
> On 6/19/07, Daniel Jacobowitz <drowfalse.org> wrote:
> > On Tue, Jun 19, 2007 at 01:22:04PM -0700, John
Bates wrote:
> > > I can't find any confirmation of support or
non-support of thread
> > > local storage on the web or in the gdb
documentation. I already tried
> > > 6.6 and it was the same problem. The test
below seems to confirm
> > > non-support on my fedora core 6 (kernel
2.6.18) x86 distribution with
> > > gdb 6.5. Please let me know if I am doing
something wrong for
> > > debugging __thread global variables.
> >
> > So far, they are only supported if you are linked
to libpthread.  Jan
> > K. was working on this earlier.
> 
> I tried linking the program with -lpthread, if that's
what you meant,
> and the same problem is occuring. Or do you mean
linking gdb with
> pthread somehow?

Normally that fixes it.  It might be some different problem,
sorry.

-- 
Daniel Jacobowitz
CodeSourcery

It would be helpful to update the GDB man/info/docs to state
that
thread local storage is not supported. It would also help to
print an
error when attempting to access TLS __thread variable that
says
"thread local storage is not supported."
Currently, GDB implies that
__thread variables are bad addresses--for example,
"Cannot access
memory at address 0x0". I have verified the same result
in GDB 6.4,
6.5 and 6.6, with and without libpthread linked with the
ELF. A simple
test case is in the email below if anyone is interested in
checking
this.

Best regards,
John


On 6/19/07, John Bates <johnnybatesgmail.com> wrote:
> I can't find any confirmation of support or non-support
of thread
> local storage on the web or in the gdb documentation. I
already tried
> 6.6 and it was the same problem. The test below seems
to confirm
> non-support on my fedora core 6 (kernel 2.6.18) x86
distribution with
> gdb 6.5. Please let me know if I am doing something
wrong for
> debugging __thread global variables.
>
> Thanks,
> John
>
>
> --- begin main.cpp ---
> __thread int tlstest = 5;
>
> int main()
> {
>         tlstest = 4; // line 5
>         return 0;
> }
>
> --- begin Makefile ---
> CXXFLAGS += -g
> main : main.o
>
> jbateslocalhost:~/samples/tls_test$ make
> g++ -g   -c -o main.o main.cpp
> cc   main.o   -o main
> jbateslocalhost:~/samples/tls_test$ gdb main
> GNU gdb Red Hat Linux (6.5-15.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public
License, and you are
> welcome to change it and/or distribute copies of it
under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type
"show warranty" for details.
> This GDB was configured as
"i386-redhat-linux-gnu"...Using host
> libthread_db library
"/lib/libthread_db.so.1".
>
> (gdb) b main.cpp:5
> Breakpoint 1 at 0x8048352: file main.cpp, line 5.
> (gdb) run
> Starting program: /home/jbates/samples/tls_test/main
>
> Breakpoint 1, main () at main.cpp:5
> 5               tlstest = 4;
> (gdb) p tlstest
> Cannot access memory at address 0x0
> (gdb)
>

"John Bates" <johnnybatesgmail.com> writes:
> It would be helpful to update the GDB man/info/docs to
state that
> thread local storage is not supported. It would also
help to print an
> error when attempting to access TLS __thread variable
that says
> "thread local storage is not supported."
Currently, GDB implies that
> __thread variables are bad addresses--for example,
"Cannot access
> memory at address 0x0". I have verified the same
result in GDB 6.4,
> 6.5 and 6.6, with and without libpthread linked with
the ELF. A simple
> test case is in the email below if anyone is interested
in checking
> this.

GDB does support thread-local storage --- but you need to
link your
program against -lpthread.

$ cat tls.c
__thread int i;

int
main (int argc, char **argv)
{
  i = 5;
  return i;
}
$ gcc -g tls.c -o tls -lpthread
$ gdb tls
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) start
Breakpoint 1 at 0x8048382: file tls.c, line 6.
Starting program: /home/jimb/play/tls 
[Thread debugging using libthread_db enabled]
[New Thread -1208985920 (LWP 7664)]
[Switching to Thread -1208985920 (LWP 7664)]
main () at tls.c:6
6         i = 5;
(gdb) p i
$1 = 0
(gdb) step
7         return i;
(gdb) p i
$2 = 5
(gdb) info address i
Symbol "i" is a thread-local variable at offset 0
in the thread-local storage for `/home/jimb/play/tls'.
(gdb) 

The current GDB sources do print a slightly more helpful
error message
when they can't do this:

$ gcc -g tls.c -o tls
$ gdb tls
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) start
Breakpoint 1 at 0x8048352: file tls.c, line 6.
Starting program: /home/jimb/play/tls 
main () at tls.c:6
6         i = 5;
(gdb) print i
Cannot find thread-local variables on this target
(gdb) 

This doesn't suggest the workaround of linking against
-lpthread.

Interesting.. it does work with C, but not with C++. I tried
-lpthread
in all cases with a C++ build (on fedora core and debian)
with the
same problem.

jbatespsycho:~/test/gdbtls$ mv tls.c tls.cpp
jbatespsycho:~/test/gdbtls$ gcc -g tls.cpp -o tls
-lpthread
jbatespsycho:~/test/gdbtls$ gdb tls
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i486-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) start
Breakpoint 1 at 0x8048392: file tls.cpp, line 6.
Starting program: /home/jbates/test/gdbtls/tls
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1209833792 (LWP 4199)]
[Switching to Thread -1209833792 (LWP 4199)]
main () at tls.cpp:6
6        i = 5;
(gdb) p i
Cannot access memory at address 0x0
(gdb)

On 6/26/07, Jim Blandy <jimbcodesourcery.com>
wrote:
>
> "John Bates" <johnnybatesgmail.com> writes:
> > It would be helpful to update the GDB
man/info/docs to state that
> > thread local storage is not supported. It would
also help to print an
> > error when attempting to access TLS __thread
variable that says
> > "thread local storage is not supported."
Currently, GDB implies that
> > __thread variables are bad addresses--for example,
"Cannot access
> > memory at address 0x0". I have verified the
same result in GDB 6.4,
> > 6.5 and 6.6, with and without libpthread linked
with the ELF. A simple
> > test case is in the email below if anyone is
interested in checking
> > this.
>
> GDB does support thread-local storage --- but you need
to link your
> program against -lpthread.
>
> $ cat tls.c
> __thread int i;
>
> int
> main (int argc, char **argv)
> {
>   i = 5;
>   return i;
> }
> $ gcc -g tls.c -o tls -lpthread
> $ gdb tls
> GNU gdb Red Hat Linux (6.5-15.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public
License, and you are
> welcome to change it and/or distribute copies of it
under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type
"show warranty" for details.
> This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
>
> (gdb) start
> Breakpoint 1 at 0x8048382: file tls.c, line 6.
> Starting program: /home/jimb/play/tls
> [Thread debugging using libthread_db enabled]
> [New Thread -1208985920 (LWP 7664)]
> [Switching to Thread -1208985920 (LWP 7664)]
> main () at tls.c:6
> 6         i = 5;
> (gdb) p i
> $1 = 0
> (gdb) step
> 7         return i;
> (gdb) p i
> $2 = 5
> (gdb) info address i
> Symbol "i" is a thread-local variable at
offset 0 in the thread-local storage for
`/home/jimb/play/tls'.
> (gdb)
>
> The current GDB sources do print a slightly more
helpful error message
> when they can't do this:
>
> $ gcc -g tls.c -o tls
> $ gdb tls
> GNU gdb Red Hat Linux (6.5-15.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public
License, and you are
> welcome to change it and/or distribute copies of it
under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type
"show warranty" for details.
> This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
>
> (gdb) start
> Breakpoint 1 at 0x8048352: file tls.c, line 6.
> Starting program: /home/jimb/play/tls
> main () at tls.c:6
> 6         i = 5;
> (gdb) print i
> Cannot find thread-local variables on this target
> (gdb)
>
> This doesn't suggest the workaround of linking against
-lpthread.
>

"John Bates" <johnnybatesgmail.com> writes:
> Interesting.. it does work with C, but not with C++. I
tried -lpthread
> in all cases with a C++ build (on fedora core and
debian) with the
> same problem.

Yes, quite interesting.  Filed as GDB bug 2279:

----

Description: 	See how-to-repeat.

GDB seems to create two symbol table entries for 'i', one
with LOC_UNRESOLVED and one with LOC_COMPUTED; it doesn't
recognize that the first die is just a specification for the
second.

If you remove the __thread qualifier, GDB still creates the
two symtab entries, but can print its value.  I think this
is because GDB tries to handle LOC_UNRESOLVED symbols by
falling back to the minsyms, but in the TLS case the
minsym's value is the variable's TLS offset.

So there may be two bugs to fix here:
- dwarf2read shouldn't be creating two symtab entries for
'i'.
- the LOC_UNRESOLVED fallback code shouldn't try to use
STT_TLS minsym values as addresses.

How-To-Repeat: 	$ cat tls.c
__thread int i;

int
main (int argc, char **argv)
{
  i = 5;
  return i;
}
$ g++ -g tls.c -o tls -lpthread
$ readelf -d tls

Dynamic section at offset 0x508 contains 24 entries:
  Tag        Type                         Name/Value
0x00000001 (NEEDED)                     Shared library:
[libpthread.so.0]
0x00000001 (NEEDED)                     Shared library:
[libstdc++.so.6]
0x00000001 (NEEDED)                     Shared library:
[libm.so.6]
0x00000001 (NEEDED)                     Shared library:
[libgcc_s.so.1]
0x00000001 (NEEDED)                     Shared library:
[libc.so.6]
0x0000000c (INIT)                       0x80482fc
0x0000000d (FINI)                       0x80484c8
0x6ffffef5 (GNU_HASH)                   0x8048168
0x00000005 (STRTAB)                     0x80481e8
0x00000006 (SYMTAB)                     0x8048188
0x0000000a (STRSZ)                      176 (bytes)
0x0000000b (SYMENT)                     16 (bytes)
0x00000015 (DEBUG)                      0x0
0x00000003 (PLTGOT)                     0x80495f4
0x00000002 (PLTRELSZ)                   16 (bytes)
0x00000014 (PLTREL)                     REL
0x00000017 (JMPREL)                     0x80482ec
0x00000011 (REL)                        0x80482e4
0x00000012 (RELSZ)                      8 (bytes)
0x00000013 (RELENT)                     8 (bytes)
0x6ffffffe (VERNEED)                    0x80482a4
0x6fffffff (VERNEEDNUM)                 2
0x6ffffff0 (VERSYM)                     0x8048298
0x00000000 (NULL)                       0x0
$ ~/gdb/pub/bin/gdb tls
GNU gdb 6.6.50.20070625-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library
"/lib/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x8048402: file tls.c, line 6.
Starting program: /home/jimb/play/tls
[Thread debugging using libthread_db enabled]
[New Thread 0xb7feb6d0 (LWP 9387)]
[Switching to Thread 0xb7feb6d0 (LWP 9387)]
main () at tls.c:6
6         i = 5;
Current language:  auto; currently c++
(gdb) print i
Cannot access memory at address 0x0
(gdb) quit
The program is running.  Exit anyway? (y or n) y
$ readelf -wi tls
The section .debug_info contains:

  Compilation Unit  offset 0x0:
   Length:        201
   Version:       2
   Abbrev Offset: 0
   Pointer Size:  4
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_stmt_list   : 0
     DW_AT_high_pc     : 0x8048419
     DW_AT_low_pc      : 0x80483f4
     DW_AT_producer    : GNU C++ 4.1.1 20070105 (Red Hat
4.1.1-51)
     DW_AT_language    : 4      (C++)
     DW_AT_name        : tls.c
     DW_AT_comp_dir    : /home/jimb/play
<1><59>: Abbrev Number: 2 (DW_TAG_subprogram)
     DW_AT_sibling     : <8f>
     DW_AT_external    : 1
     DW_AT_name        : main
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 4
     DW_AT_type        : <8f>
     DW_AT_low_pc      : 0x80483f4
     DW_AT_high_pc     : 0x8048419
     DW_AT_frame_base  : 0      (location list)
<2><76>: Abbrev Number: 3
(DW_TAG_formal_parameter)
     DW_AT_name        : argc
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 4
     DW_AT_type        : <8f>
<2><82>: Abbrev Number: 3
(DW_TAG_formal_parameter)
     DW_AT_name        : argv
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 4
     DW_AT_type        : <96>
<1><8f>: Abbrev Number: 4 (DW_TAG_base_type)
     DW_AT_name        : int
     DW_AT_byte_size   : 4
     DW_AT_encoding    : 5      (signed)
<1><96>: Abbrev Number: 5 (DW_TAG_pointer_type)
     DW_AT_byte_size   : 4
     DW_AT_type        : <9c>
<1><9c>: Abbrev Number: 5 (DW_TAG_pointer_type)
     DW_AT_byte_size   : 4
     DW_AT_type        : <a2>
<1><a2>: Abbrev Number: 4 (DW_TAG_base_type)
     DW_AT_name        : char
     DW_AT_byte_size   : 1
     DW_AT_encoding    : 6      (signed char)
<1><aa>: Abbrev Number: 6 (DW_TAG_namespace)
     DW_AT_sibling     : <c0>
     DW_AT_name        : ::
     DW_AT_decl_file   : 2
     DW_AT_decl_line   : 0
<2><b4>: Abbrev Number: 7 (DW_TAG_variable)
     DW_AT_name        : i
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 1
     DW_AT_type        : <8f>
     DW_AT_external    : 1
     DW_AT_declaration : 1
<1><c0>: Abbrev Number: 8 (DW_TAG_variable)
     DW_AT_specification: <b4>
     DW_AT_location    : 6 byte block: 3 0 0 0 0 e0    
(DW_OP_addr: 0; DW_OP_GNU_push_tls_address)

$