From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26622 invoked by alias); 1 Dec 2008 18:30:44 -0000 Received: (qmail 26612 invoked by uid 22791); 1 Dec 2008 18:30:43 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Dec 2008 18:30:00 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id mB1ITuXl515072 for ; Mon, 1 Dec 2008 18:29:56 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB1ITu104161650 for ; Mon, 1 Dec 2008 19:29:56 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB1ITu4c028587 for ; Mon, 1 Dec 2008 19:29:56 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id mB1ITtMU028584; Mon, 1 Dec 2008 19:29:55 +0100 Message-Id: <200812011829.mB1ITtMU028584@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 1 Dec 2008 19:29:55 +0100 Subject: Re: [patch] Accessing tls variables across files causes a bug To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Mon, 01 Dec 2008 18:30:00 -0000 From: "Ulrich Weigand" Cc: gary@intrepid.com (Gary Funck), vinay@linux.vnet.ibm.com (Vinay Sridhar), gdb-patches@sources.redhat.com, drow@false.org (Daniel Jacobowitz), luisgpm@linux.vnet.ibm.com In-Reply-To: <20081201141408.GA10447@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Dec 01, 2008 03:14:08 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00007.txt.bz2 Jan Kratochvil wrote: > + /* SYMBOL_VALUE_ADDRESS should return the translated address. */ I'm not sure I understand this comment -- the translated address of a thread-local variable obviously depends on the thread in which it is evaluated, so how should a single location like SYMBOL_VALUE_ADDRESS be able to hold that value for all threads? Otherwise, I guess it makes sense to do that translation for LOC_UNRESOLVED TLS symbols in read_var_value, just like it would be done for LOC_COMPUTED symbols; in both cases assuming evaluation in the current thread. > + /* SYMBOL_VALUE_ADDRESS should return the translated address. */ > + if (section > + && (section->the_bfd_section->flags & SEC_THREAD_LOCAL) != 0) > + { > + printf_filtered (_("a thread-local variable at offset %s " > + "at final address "), paddr_nz (load_addr)); > + load_addr = target_translate_tls_address (section->objfile, > + load_addr); > + } Again, I think "at final address" may be misleading; if we give an absolute address, it should explicitly mention it is relative to the current thread. On the other hand, I'm wondering if we should perform the resolution here at all; isn't "info address" also allowed when the target is not actually running, so we don't even have a current thread? In the LOC_COMPUTED case, we'd output something like "at offset ... in the thread-local storage for ...". For consistency reasons, I'd prefer to have the same output in the LOC_UNDEFINED case as well. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com