From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22779 invoked by alias); 21 Jun 2002 01:35:29 -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 22772 invoked from network); 21 Jun 2002 01:35:28 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 21 Jun 2002 01:35:28 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 902373D37; Thu, 20 Jun 2002 21:35:25 -0400 (EDT) Message-ID: <3D1282DD.7000508@cygnus.com> Date: Thu, 20 Jun 2002 18:35:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: GDB support for thread-local storage References: <20020619160004.38A625EA11@zwingli.cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00157.txt.bz2 > I've posted a note to the Dwarf mailing list, describing the > DW_OP_push_tls_address approach, and saying that we'll experiment with > this as a GNU extension to Dwarf and write back when we've actually > got something working. Hmm, would you be able to post the prososal here? > 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. > 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). 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. BTW, what happens if the target doesn't have execution (i.e. a corefile). Andrew (Use thread_local_static rather than thr_tls in function names)