From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2987 invoked by alias); 13 Sep 2006 18:49:12 -0000 Received: (qmail 2971 invoked by uid 22791); 13 Sep 2006 18:49:12 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 13 Sep 2006 18:49:07 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GNZnF-0004lZ-3z; Wed, 13 Sep 2006 14:49:05 -0400 Date: Wed, 13 Sep 2006 18:49:00 -0000 From: Daniel Jacobowitz To: libc-alpha@sourceware.org, gdb@sourceware.org Subject: Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp() Message-ID: <20060913184905.GA18159@nevyn.them.org> Mail-Followup-To: libc-alpha@sourceware.org, gdb@sourceware.org References: <20060908102235.GA31335@host0.dyn.jankratochvil.net> <20060910142723.GA28131@nevyn.them.org> <20060913130532.GA21977@host0.dyn.jankratochvil.net> <20060913131948.GA8624@nevyn.them.org> <20060913183705.GA1443@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913183705.GA1443@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00077.txt.bz2 On Wed, Sep 13, 2006 at 08:37:05PM +0200, Jan Kratochvil wrote: > 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. I think you've missed my point here: we can get at errno in a single threaded program by bypassing libthread_db. The DTV is not an indirection; td_thr_tls_get_addr is an abstraction on top of direct DTV access. > > 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? Yes. This isn't hard. > > - 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'? Well, right now that's only for thread_db usage. I hadn't thought about it, but we could use it directly from GDB; I guess that would work fine. We could move those thread-db related symbols which provide information about libc (not libpthread) data structures to libc.so and look them up directly. I'm not sure how this would work with static linking however. Being able to do whatever we do for dynamic apps for static ones also would be desirable. Also, distributions generally strip symbols from libc.so; we'll have to let them know to give it the same special treatment they already give libpthread.so. -- Daniel Jacobowitz CodeSourcery