From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6158 invoked by alias); 21 Jun 2002 19:49:47 -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 6132 invoked from network); 21 Jun 2002 19:49:45 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 21 Jun 2002 19:49:45 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id D579C5EA11; Fri, 21 Jun 2002 14:49:43 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> <3D1282DD.7000508@cygnus.com> From: Jim Blandy Date: Fri, 21 Jun 2002 12:49:00 -0000 In-Reply-To: <3D1282DD.7000508@cygnus.com> 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/msg00171.txt.bz2 Andrew Cagney writes: > > For STABS, we can simply invent a new symbol type, whose value is the > > offset within the thread-local storage block for the current thread > > for the module containing the stab. I haven't written up a real > > proposal for STABS yet. > > On Linux, Ulrich Drepper has added the following function to > > libthread_db: > > Has solaris, or even MS, done anything in this area? The > LOC_THREAD_LOCAL_STATIC must have come from somewhere, dig dig, you > may want to look at what HP/UX is getting up to. I didn't see anything in the Solaris "Stabs Interface Manual" (distributed with the Solaris toolchain, not publicly) about it. HP implements something much simpler. It doesn't deal with thread-local storage in PIC code; the initialization image is laid out completely at static link time. It's thread-local storage in dynamically loaded libraries that introduces all the hair. > > If you're not convinced it should be a target method, consider this: > > Remember that libthread_db isn't clean for cross-debugging. It's a > > target library. So at the moment, there are cases where gdbserver > > loads and uses libthread_db, not GDB itself. In those cases, the > > tls_get_addr request needs to be sent across the network connection to > > gdbserver, td_thr_tls_get_addr needs to be invoked there, and the > > answer needs to be sent back. By making tls_get_addr a target method, > > it's easy for the remote protocol layer to provide its own definition > > of the method and send a packet across for the request. > > Similar to this, both SOFTWARE_SINGLESTEP and hardware breakpoints are > ment to be implemented with support from both the target vector and > the architecture vector. By doing that, a sequence like: > > can target single step? > yes, step target > else > use architecture to software singlestep target > > can be implemented (in both cases it isn't so it can't, ulgh). Yes, I remember you saying this before; I was trying to follow your lead here. > However, in the case of the above, is the architecture method needed? > Given that th only thing implementing this will be the above GNU/Linux > thread-db library, and GDB's linux thread code will know to call that > directly. I don't think that's so. As I say, Uli is pretty much just following what the IA-64 and SPARC people have done for their ABI's, and introducing a new scheme for the IA-32. So we should expect this feature to crop up on other platforms. As far as the gdbarch method is concerned, I dunno. It's true that nobody is actually going to define the method at the moment. But I don't see why embedded ABI's wouldn't want to support __thread; the whole point is that __thread can be faster and have less overhead than the pthreads alternative, which (it seems to me) would make it very attractive to the embedded world. So I would expect the gdbarch method to be used for the first embedded ABI that supports __thread. Should we put off adding the gdbarch method until someone is actually going to define it?