From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2282 invoked by alias); 26 Jun 2002 19:37:39 -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 2275 invoked from network); 26 Jun 2002 19:37:38 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 26 Jun 2002 19:37:38 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id C963F5EA11; Wed, 26 Jun 2002 14:37:36 -0500 (EST) To: Daniel Jacobowitz Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage 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> <20020622055716.GA7243@nevyn.them.org> From: Jim Blandy Date: Wed, 26 Jun 2002 12:37:00 -0000 In-Reply-To: <20020622055716.GA7243@nevyn.them.org> Message-ID: 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/msg00272.txt.bz2 Daniel Jacobowitz writes: > 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. Well, td_thr_tls_get_addr only makes two calls to ps_pdread. The first one is a big one, unfortunately --- it reads a pretty large structure. > 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. It seems to me that the right place to handle this is in proc-service.c, or in the layers below that --- those layers may know the inferior is stopped, and be able to cache memory contents, etc.