From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12142 invoked by alias); 18 Oct 2014 21:27:35 -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 12111 invoked by uid 89); 18 Oct 2014 21:27:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 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; Sat, 18 Oct 2014 21:27:34 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9ILRVZg031195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 18 Oct 2014 17:27:31 -0400 Received: from host2.jankratochvil.net (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9ILRRDX028165 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sat, 18 Oct 2014 17:27:30 -0400 Date: Sat, 18 Oct 2014 21:27:00 -0000 From: Jan Kratochvil To: Rich Felker Cc: libc-alpha@sourceware.org, gdb-patches@sourceware.org Subject: Re: [libc patch] __tls_get_addr with link_map * instead of modid Message-ID: <20141018212727.GA27805@host2.jankratochvil.net> References: <20141018201540.GA26252@host2.jankratochvil.net> <20141018212048.GH32028@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141018212048.GH32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00502.txt.bz2 On Sat, 18 Oct 2014 23:20:48 +0200, Rich Felker wrote: > > 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? When the inferior is running the relocation is already resolved. So GDB can just read the module id from relocation's location. The problem is that '.rela.dyn' is not parsed by BFD so one would either have to extend BFD to parse it or provide a separate '.rela.dyn' parser in GDB for each arch. >From '.rela.dyn' one can find the symbol name and relocation's location. Relocation section '.rela.dyn' at offset 0x520 contains 10 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000200fd0 0000000a00000010 R_X86_64_DTPMOD64 0000000000000000 x + 0 0000000000200fd8 0000000a00000011 R_X86_64_DTPOFF64 0000000000000000 x + 0 7ac: 66 48 8d 3d 1c 08 20 data32 lea 0x20081c(%rip),%rdi # 200fd0 <_DYNAMIC+0x1d8> 7b3: 00 7b4: 66 66 48 e8 d4 fe ff data32 data32 callq 690 <__tls_get_addr@plt> 7bb: ff But that is an offtopic discussion for this patch. Jan