From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29957 invoked by alias); 18 Jul 2003 15:30:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29947 invoked from network); 18 Jul 2003 15:30:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 18 Jul 2003 15:30:19 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19dXBY-0004Y2-00; Fri, 18 Jul 2003 11:30:16 -0400 Date: Fri, 18 Jul 2003 15:30:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: gdb@sources.redhat.com Subject: Re: What to do with info addr and location expressions Message-ID: <20030718153016.GA17382@nevyn.them.org> Mail-Followup-To: Elena Zannoni , gdb@sources.redhat.com References: <16152.3014.959070.885970@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16152.3014.959070.885970@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00243.txt.bz2 On Fri, Jul 18, 2003 at 11:01:26AM -0400, Elena Zannoni wrote: > > I was looking at the tls tests, and was trying to understand why > Michael was seeing failures and I wasn't. I discovered that I was > testing the old RH gdb version which was based on a snapshot taken > befor the dwarf2loc* and dwarf2expr* files where introduced. > > Turns out that we lost a whole lot of information in the 'info address' > command. > > Before the change: > > (gdb) info address a_thread_local > Symbol "a_thread_local" is a thread-local variable at offset 0 in the thread-local storage for `/usr/src/redhat/BUILD/gdb+dejagnu-20021129-build/gdb/testsuite/gdb.threads/tls'. > (gdb) info address another_thread_local > Symbol "another_thread_local" is a thread-local variable at offset 4 in the thread-local storage for `/usr/src/redhat/BUILD/gdb+dejagnu-20021129-build/gdb/testsuite/gdb.threads/tls'. > > > > after the change: > > > (gdb) info address a_thread_local > Symbol "a_thread_local" is a variable with complex or multiple locations (DWARF2). > (gdb) info address another_thread_local > Symbol "another_thread_local" is a variable with complex or multiple locations (DWARF2). > > > Seems to me like a regression because we have lost some information. > > > Is there any way to fix this? I.e. is there any way to recalculate the > values as part of info address? Could info address call > locexpr_read_variable or a variant of it? I always found info address > quite useful. There are plenty of ways to fix it. In general, we need a location expression pretty-printer - this is quite complicated, so no one's done it yet. However, in specific, take a look at locexpr_describe_location. You could just add another case which recognizes the form GCC emits for thread-local variables to fix the regression. Is that good enough? > BTW, when this changes were checked in, a few things used by TLS > weren't cleaned up properly, like the global is_thread_local and the > enum value LOC_THREAD_LOCAL_STATIC, with the cases in printcmd.c and > findvar.c. Yes, they're dead now. Since the changes haven't caused any problems I suppose they could be removed. I was going to get is_thread_local when I had finished with all the other users of decode_locdesc, but I haven't had a chance to do that yet. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer