From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7167 invoked by alias); 18 Jul 2003 14:54:17 -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 6950 invoked from network); 18 Jul 2003 14:54:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jul 2003 14:54:16 -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 h6IEsFH19833 for ; Fri, 18 Jul 2003 10:54:15 -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 h6IEsFI29859 for ; Fri, 18 Jul 2003 10:54:15 -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 h6IEsE532049 for ; Fri, 18 Jul 2003 10:54:14 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 2B0672CA3D; Fri, 18 Jul 2003 11:01:27 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16152.3014.959070.885970@localhost.redhat.com> Date: Fri, 18 Jul 2003 14:54:00 -0000 To: gdb@sources.redhat.com Subject: What to do with info addr and location expressions X-SW-Source: 2003-07/txt/msg00242.txt.bz2 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. For the particular case at hand one could "cheat" and do like it was done before, where, upon reading the value from the top of the stack (which for the DW_GNU_push_tls_address case is the offset), such value would be saved in the SYMBOL_VALUE field. If it was there, info address would be able to access it. The offset is not changing over time. 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. elena