From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25180 invoked by alias); 13 Sep 2006 18:37:14 -0000 Received: (qmail 25161 invoked by uid 22791); 13 Sep 2006 18:37:13 -0000 X-Spam-Check-By: sourceware.org Received: from 195.22.55.53.adsl.nextra.cz (HELO host0.dyn.jankratochvil.net) (195.22.55.53) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Sep 2006 18:37:09 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.13.8/8.13.8) with ESMTP id k8DIb5rv019158; Wed, 13 Sep 2006 20:37:05 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.13.8/8.13.8/Submit) id k8DIb5Z4019157; Wed, 13 Sep 2006 20:37:05 +0200 Date: Wed, 13 Sep 2006 18:37:00 -0000 From: Jan Kratochvil To: libc-alpha@sourceware.org, gdb@sourceware.org Subject: Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp() Message-ID: <20060913183705.GA1443@host0.dyn.jankratochvil.net> References: <20060908102235.GA31335@host0.dyn.jankratochvil.net> <20060910142723.GA28131@nevyn.them.org> <20060913130532.GA21977@host0.dyn.jankratochvil.net> <20060913131948.GA8624@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913131948.GA8624@nevyn.them.org> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00076.txt.bz2 Hi, also regarding making `__libc_version' public - it would be even useful to check matching version of libc vs. libpthread as currently mixing various versions has unpolite results. On Wed, 13 Sep 2006 15:19:48 +0200, Daniel Jacobowitz wrote: ... > GDB shouldn't access TLS the same way the application does (by calling > __tls_get_addr, which might e.g. cause allocation of a new TLS block). glibc nptl_db already accesses inferior TLS IMO in a safe unmodifying way. Everything through td_thr_tls_get_addr() ... Without libthread_db support the TLS base can be queried by ps_get_thread_area(), using read_register() etc., done in the patch for TCB `pointer_guard'. Accessing DTV fields is just some indirection, the problem is mapping the module address to module id as you describe below. > But it could find the DTV directly and perform its own > lookup, based on knowledge of the platform ABI. (Probably described above...) > The symbol value's easily available in the symbol table. The module > number is harder. It's in the result from dl_iterate_phdr, which is > workable but very awkward for GDB to use. And it's in the link_map, > but not at a public offset, so we can't find it there. > > Options I see: > - Make GDB call dl_iterate_phdr to get the module numbers. It would be needed to be called remotely in the inferior process, wouldn't be? > - Provide them in the public portion of the link map. `libpthread.so' already contains public `_thread_db_link_map_l_tls_modid', doesn't it just mean moving (or appropriately providing) this public symbol from `libpthread.so' to `libc.so'? > - Provide a function in ld.so to translate a link map into its TLS > module ID, for gdb use. I hope you intend function callable from the gdb process; I hope it is clear calling inferior's function (using dummy frame?) is not suitable. ... > > * Providing full custom TLS resolving for gdb - no glibc change needed. > > I think this is what I described above. Partially, in this case I would choose "link map" access with providing target-dependent gdb-side link map offset (ugly, I know). On Wed, 13 Sep 2006 15:19:48 +0200, Daniel Jacobowitz wrote: > On Wed, Sep 13, 2006 at 03:05:32PM +0200, Jan Kratochvil wrote: ... > > Besides longjmp() target PTR_DEMANGLE()ing there is also need to access glibc > > TLS symbol `errno' but - in fact - AFAIK no other TLS symbol. > > You're combining two different problems here, [ Sincerely thanks for pointing out my possible mistake. Just in general - I know the differences, my patches would not work otherwise; I know DTV, I just did not remember that acronym it is that structure before. ] Regards, Jan