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

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

[John Bates]

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

jbates@localhost:~/samples/tls_test$ make
g++ -g   -c -o main.o main.cpp
cc   main.o   -o main
jbates@localhost:~/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)

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

[Daniel Jacobowitz]

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

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

[John Bates]

On 6/19/07, Daniel Jacobowitz <drow@false.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

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

[Daniel Jacobowitz]

On Tue, Jun 19, 2007 at 01:56:51PM -0700, John Bates wrote:
> On 6/19/07, Daniel Jacobowitz <drow@false.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

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

[John Bates]

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 <johnnybates@gmail.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
>
> jbates@localhost:~/samples/tls_test$ make
> g++ -g   -c -o main.o main.cpp
> cc   main.o   -o main
> jbates@localhost:~/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)
>

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

[Jim Blandy]

"John Bates" <johnnybates@gmail.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.

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

[John Bates]

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.

jbates@psycho:~/test/gdbtls$ mv tls.c tls.cpp
jbates@psycho:~/test/gdbtls$ gcc -g tls.cpp -o tls -lpthread
jbates@psycho:~/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 <jimb@codesourcery.com> wrote:
>
> "John Bates" <johnnybates@gmail.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.
>

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

[Jim Blandy]

"John Bates" <johnnybates@gmail.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)

$ 

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

[ajitnayak]

I was trying the same program(tls.cpp)  with gdb-6.7  and ran into the same
problem.  
In C++ gdb-6.7 can not access _thread variables , however it works fine with
C. I had linked my tls.cpp with pthread lib.  

I was wondering  if there is any update on this or, if I am missing
something. Below is my program and gdb output.

threads$ cat tls.cpp
__thread int i;

int
main (int argc, char **argv)
{
  i = 5;
  return i;
}

threads$ g++ -g tls.cpp -o tls -lpthread
threads$ gdb tls
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x80483a8: file tls.cpp, line 6.
Starting program: /tmp/threads/tls
[Thread debugging using libthread_db enabled]
[New Thread 0xb7fdbac0 (LWP 26922)]
[Switching to Thread 0xb7fdbac0 (LWP 26922)]
main (argc=1, argv=0xbfea87a4) at tls.cpp:6
6         i = 5;
(gdb) p i
Cannot access memory at address 0x0
(gdb)

Will appreciate any help.

thanks,
Ajit.


John Bates wrote:
> 
> 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.
> 
> jbates@psycho:~/test/gdbtls$ mv tls.c tls.cpp
> jbates@psycho:~/test/gdbtls$ gcc -g tls.cpp -o tls -lpthread
> jbates@psycho:~/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 <jimb@codesourcery.com> wrote:
>>
>> "John Bates" <johnnybates@gmail.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.
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/thread-local-storage-%28__thread%29-variables-aren%27t-working-in-gdb-6.5-6.6--tp11202198p22974723.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

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

[Jan Kratochvil]

Hi Ajit,

[ http://sourceware.org/bugzilla/show_bug.cgi?id=9384 ]

On Mon, 13 Apr 2009 16:35:30 +0200, ajit nayak wrote:
[snip]
> Below  are the details. I did try with gdb-6.8 (after compining both with
> g++), but no luck..ran into the same problem.

if you try CVS HEAD it should work:
	cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb


> However if I compile with gcc with a ".c" file  (NOT .cpp) extension (gcc -g
> tls.cpp  -o tls -lpthread), everyting works fine, i can access teh thread
> local variable from gdb.  But my requirement is to compile .cpp files with
> g++ .

Checked the difference, both g++-4.3 and gcc-4.1 use more simple format as
read by `readelf -wi':
 <1><88>: Abbrev Number: 7 (DW_TAG_variable)
    <89>   DW_AT_name        : i	
[snip]
    <91>   DW_AT_external    : 1	
    <92>   DW_AT_location    : 10 byte block: 3 0 0 0 0 0 0 0 0 e0 	(DW_OP_addr: 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)

while g++-4.1 uses:
 <2><d2>: Abbrev Number: 7 (DW_TAG_variable)
     DW_AT_name        : i	
[snip]
     DW_AT_external    : 1	
     DW_AT_declaration : 1	
 <1><de>: Abbrev Number: 8 (DW_TAG_variable)
     DW_AT_specification: <d2>	
     DW_AT_location    : 10 byte block: 3 0 0 0 0 0 0 0 0 e0 	(DW_OP_addr: 0; DW_OP_GNU_push_tls_address)

Which is perfectly valid DWARF but current GDB cannot cope with it.

It starts working in post-6.8 FSF GDB because it gets resolved as an external
TLS reference.  External TLS references did not work before.  It is not
completely correct but in practice it works.  Fixed by this patch:
http://sourceware.org/ml/gdb/2008-07/threads.html#00341
http://sourceware.org/ml/gdb-patches/2008-08/threads.html#00026
http://sourceware.org/ml/gdb-patches/2008-09/threads.html#00204
http://sourceware.org/ml/gdb-patches/2008-11/threads.html#00706
http://sourceware.org/ml/gdb-patches/2008-12/threads.html#00003
http://sourceware.org/ml/gdb-cvs/2008-12/msg00009.html


> [nz@TT4-A022 thread]$ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> *[nz@TT4-A022 thread]$  g++ -g tls.cpp -o tls -lpthread*

=> Also using g++43 (bare g++ is 4.1 on RHEL-5.2) would workaround GDB.


HTH,
Jan