From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12211 invoked by alias); 23 Oct 2014 12:52:24 -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 12192 invoked by uid 89); 23 Oct 2014 12:52:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 23 Oct 2014 12:52:14 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NCqCkJ014677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 08:52:12 -0400 Received: from host2.jankratochvil.net (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NCq84o024186 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Oct 2014 08:52:11 -0400 Date: Thu, 23 Oct 2014 12:52:00 -0000 From: Jan Kratochvil To: Alexandre Oliva Cc: libc-alpha@sourceware.org, gdb-patches@sourceware.org Subject: Re: [libc patch] __tls_get_addr with link_map * instead of modid Message-ID: <20141023125208.GA4845@host2.jankratochvil.net> References: <20141018201540.GA26252@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00603.txt.bz2 On Thu, 23 Oct 2014 12:02:34 +0200, Alexandre Oliva wrote: > dlinfo offers operations to both map a link_map (AKA dlopen handle) to > the modid, and to get the TLS base address for that link_map. I suppose > calling dlinfo directly is not an option, since there's no guarantee > that libdl will have been linked in. Thanks for the dlinfo() information; but I agree libdl is not an option for the "GDB JIT" purpose. > However, the implementat of dlinfo RTLD_DI_TLS_DATA relies on > _dl_tls_get_addr_soft, that not only takes a struct link_map*, but also > refrains from assigning a TLS segment for the module in the running > thread when one isn't allocated already. I think this would be > preferrable behavior for a debugger, to avoid heisenbugs. OK, I will try to use _dl_tls_get_addr_soft for GDB as is. Although I think the TLS segment allocation would be better for the "GDB JIT" purpose. Imagine an inferior shared library: __thread int tlsvar; And user asking for: (gdb) compile code tlsvar = 5; I think it is better to do the TLS segment allocation than to refuse the command to the user. But someone may have an opposite opinion. > This symbol is not exported by ld.so, but this shouldn't stop GDB from > using it, since it is present in the symbol table as a local (hidden) > symbol. It is OK although when we talk about it it is not perfect. Some distros strip all shared libraries and then they have problem libthread_db cannot find libpthread .symtab-only _thread_db_* symbols. _dl_tls_get_addr_soft() will have the same problem. But that is mostly off-topic here now. Thanks, Jan