From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11421 invoked by alias); 13 Apr 2009 16:09:10 -0000 Received: (qmail 11409 invoked by uid 22791); 13 Apr 2009 16:09:06 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Apr 2009 16:09:01 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3DG8xHF027244 for ; Mon, 13 Apr 2009 12:08:59 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3DG918j018027 for ; Mon, 13 Apr 2009 12:09:01 -0400 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3DG8wUO024223 for ; Mon, 13 Apr 2009 12:08:59 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n3DG8tBJ013239; Mon, 13 Apr 2009 18:08:56 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.2/Submit) id n3DG8r82013234; Mon, 13 Apr 2009 18:08:53 +0200 Date: Mon, 13 Apr 2009 19:00:00 -0000 From: Jan Kratochvil To: ajit nayak Cc: gdb@sourceware.org, John Bates Subject: Re: thread local storage (__thread) variables aren't working in gdb 6.5/6.6? Message-ID: <20090413160853.GA11305@host0.dyn.jankratochvil.net> References: <22974723.post@talk.nabble.com> <20090409200657.GA22217@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00101.txt.bz2 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>: Abbrev Number: 7 (DW_TAG_variable) DW_AT_name : i [snip] DW_AT_external : 1 DW_AT_declaration : 1 <1>: Abbrev Number: 8 (DW_TAG_variable) DW_AT_specification: 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