From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2569 invoked by alias); 22 Jun 2002 05:57:23 -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 2237 invoked from network); 22 Jun 2002 05:57:16 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Jun 2002 05:57:16 -0000 Received: from 01-058.118.popsite.net ([66.19.120.58] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17LdtX-00021z-00; Sat, 22 Jun 2002 00:57:12 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17Ldtc-0001uE-00; Sat, 22 Jun 2002 01:57:16 -0400 Date: Fri, 21 Jun 2002 22:57:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage Message-ID: <20020622055716.GA7243@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb@sources.redhat.com References: <20020621014821.GA7608@nevyn.them.org> <3D135FE5.6090605@cygnus.com> <20020621173249.GA11443@nevyn.them.org> <20020621201716.GA23307@nevyn.them.org> <20020621210302.GA25010@nevyn.them.org> <3D139E9D.70401@cygnus.com> <20020621215532.GA27228@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00196.txt.bz2 On Fri, Jun 21, 2002 at 06:14:41PM -0500, Jim Blandy wrote: > > 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. Well, libthread_db is still pretty expensive. It generally does a substantial amount of memory access to the inferior. Cheaper than a function call, but not so much. Part of that is the ridiculous way we use it and abuse the thread_alive checks at every opportunity. If you benchmark some operations on libthread_db/native gdb, and gdb/local gdbserver (which uses thread_db, but makes some documented assumptions about the threading model, and also supports partial stops which I haven't worked out how to do in GDB proper) you'll see that the overhead of the remote protocol is sometimes less than the overhead of native thread_db. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer