From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22139 invoked by alias); 23 Oct 2014 10:03:41 -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 22119 invoked by uid 89); 23 Oct 2014 10:03:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 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 10:03:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9NA3bGO027405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 23 Oct 2014 06:03:37 -0400 Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9NA3XBp008808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Oct 2014 06:03:35 -0400 Received: from free.home (free.home [172.31.160.1]) by freie.home (8.14.8/8.14.8) with ESMTP id s9NA2YHD008822; Thu, 23 Oct 2014 08:02:35 -0200 From: Alexandre Oliva 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 References: <20141018201540.GA26252@host2.jankratochvil.net> Date: Thu, 23 Oct 2014 10:03:00 -0000 In-Reply-To: <20141018201540.GA26252@host2.jankratochvil.net> (Jan Kratochvil's message of "Sat, 18 Oct 2014 22:15:40 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2014-10/txt/msg00602.txt.bz2 On Oct 18, 2014, Jan Kratochvil wrote: > * A new glibc function like __tls_get_addr that takes a link_map address > rather than a module id. 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. 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. 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. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer