From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18799 invoked by alias); 18 Jul 2003 16:01:38 -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 18785 invoked from network); 18 Jul 2003 16:01:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jul 2003 16:01:37 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h6IG1aH07186 for ; Fri, 18 Jul 2003 12:01:36 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6IG1aI21182 for ; Fri, 18 Jul 2003 12:01:36 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h6IG1Z509858; Fri, 18 Jul 2003 12:01:35 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 5DF162CA3E; Fri, 18 Jul 2003 12:08:44 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16152.7052.170683.349986@localhost.redhat.com> Date: Fri, 18 Jul 2003 16:01:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , gdb@sources.redhat.com Subject: Re: What to do with info addr and location expressions In-Reply-To: <20030718153016.GA17382@nevyn.them.org> References: <16152.3014.959070.885970@localhost.redhat.com> <20030718153016.GA17382@nevyn.them.org> X-SW-Source: 2003-07/txt/msg00245.txt.bz2 Daniel Jacobowitz writes: > 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. Yes, I have looked at the function. I can see a ways to hack around the problem, but I don't see a clear proper fix that doesn't require some extensive work. Info addr was giving you a lot of info. :-( It's not just a pretty printer that is needed here. You need to compute the values, and print the address. Kind of like the 'whatis' command does wrt to 'print'. > > 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. > Yes, obviously they were dead as soon as the changes were committed. That's why I was puzzled to see that they were still there, totally dead code, w/o any comments. I'll clean that up. elena > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer