From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8382 invoked by alias); 18 Oct 2014 21:20:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8362 invoked by uid 89); 18 Oct 2014 21:20:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,SUBJ_OBFU_PUNCT_MANY,TVD_RCVD_IP autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 18 Oct 2014 21:20:53 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1XfbQe-0003z4-00; Sat, 18 Oct 2014 21:20:48 +0000 Date: Sat, 18 Oct 2014 21:20:00 -0000 From: Rich Felker To: Jan Kratochvil Cc: libc-alpha@sourceware.org, gdb-patches@sourceware.org Subject: Re: [libc patch] __tls_get_addr with link_map * instead of modid Message-ID: <20141018212048.GH32028@brightrain.aerifal.cx> References: <20141018201540.GA26252@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141018201540.GA26252@host2.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-10/txt/msg00501.txt.bz2 On Sat, Oct 18, 2014 at 10:15:40PM +0200, Jan Kratochvil wrote: > Hi, > > https://sourceware.org/glibc/wiki/Tools%20Interface%20NG > From within the inferior: Functions that are inserted into a process's > address space by the debugger need to be able to access the TLS area > for that thread. GDB can use DWARF to to find the offset within the > TLS of a variable and pass that in as a compile time offset into the > function being inserted into the traced process's address space. > However, to be able to get to the address of the TLS area for > a particular thread, it needs to know the module id to make a call to > __tls_get_addr(). This module id is burried in a private area of the > link_map data structure which is subject to change. It is therefore > proposed that we add a new function to libthread_db which extracts the > module id from the link map. > > Other option suggested by Tom Tromey is implemented by this patch: > > * A new glibc function like __tls_get_addr that takes a link_map address > rather than a module id. This sounds more appealing. I don't know how much interest you have in non-glibc systems, but from our side with musl libc, we presently don't have a libthread_db and don't plan to, so anything that makes gdb work better without it (or even just preserves current functionality without it) is preferable. > I expect I will have to also implement this Tom Tromey's suggestion to GDB but > I haven't tried to implement it yet: > > * Bake more information about struct link_map into gdb (least preferred > IMO). I think this is the worst option. > Additionally one could also fetch the module id from R_X86_64_DTPMOD64 but that > would require arch specific code in GDB. I do not plan to implement this way. I don't see how this would work; how would you request the dynamic linker to resolve that for you? Rich