From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-9272-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 23951 invoked by alias); 21 Jun 2002 23:14:44 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 23941 invoked from network); 21 Jun 2002 23:14:42 -0000
Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35)
  by sources.redhat.com with SMTP; 21 Jun 2002 23:14:42 -0000
Received: by zwingli.cygnus.com (Postfix, from userid 442)
	id 825EC5EA11; Fri, 21 Jun 2002 18:14:41 -0500 (EST)
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sources.redhat.com
Subject: Re: GDB support for thread-local storage
References: <20020619160004.38A625EA11@zwingli.cygnus.com>
	<3D1282DD.7000508@cygnus.com> <20020621014821.GA7608@nevyn.them.org>
	<3D135FE5.6090605@cygnus.com> <20020621173249.GA11443@nevyn.them.org>
	<np1yb0tmxo.fsf@zwingli.cygnus.com>
	<20020621201716.GA23307@nevyn.them.org>
	<npsn3gs68b.fsf@zwingli.cygnus.com>
	<20020621210302.GA25010@nevyn.them.org> <3D139E9D.70401@cygnus.com>
	<20020621215532.GA27228@nevyn.them.org>
From: Jim Blandy <jimb@redhat.com>
Date: Fri, 21 Jun 2002 16:14:00 -0000
In-Reply-To: <20020621215532.GA27228@nevyn.them.org>
Message-ID: <nphejwql5q.fsf@zwingli.cygnus.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-06/txt/msg00186.txt.bz2


One of the reasons I really like having libthread_db handle TLS
resolution is that the alternative is to do an inferior function call
when you reference a variable.  Check out Uli's document, at the
pointer I gave --- even the compiler will sometimes have to generate a
call to __tls_get_addr to find a __thread variable's address.

And GDB shouldn't cache this base address while the inferior runs,
either --- remember the "GDB must never lie" rule.  Evaluating `x' in
GDB had better reference the same storage that it would if the compiler
evaluated `x' at the point where the program is stopped.

So if we have trouble keeping the Insight variable window up-to-date
now...

Anyway, in that context, having libthread_db handle it all in-process
seems really nice.