From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22332 invoked by alias); 13 Sep 2006 13:20:02 -0000 Received: (qmail 22267 invoked by uid 22791); 13 Sep 2006 13:20:01 -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 13:19:50 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GNUea-0002Ji-HX; Wed, 13 Sep 2006 09:19:48 -0400 Date: Wed, 13 Sep 2006 13:20:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil Cc: libc-alpha@sourceware.org, gdb@sourceware.org Subject: Re: tcbhead_t gdb access for nonthreaded, gdb for longjmp() Message-ID: <20060913131948.GA8624@nevyn.them.org> Mail-Followup-To: Jan Kratochvil , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913130532.GA21977@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/msg00075.txt.bz2 On Wed, Sep 13, 2006 at 03:05:32PM +0200, Jan Kratochvil wrote: > > I wonder if we really need to use libthread_db here anyway. > > 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, and they're very different. The pointer_guard lives in the TCB, which is special (not normal TLS data). Normal TLS mechanisms won't work to find it. But the errno value lives in a standard TLS block. All the application needs to access it is the module number for libc.so.6 and the symbol value. 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). But it could find the DTV directly and perform its own lookup, based on knowledge of the platform ABI. (You mentioned earlier not knowing what the DTV was; if that's still the case, please read Ulrich's TLS paper, which explains it very well). 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. - Provide them in the public portion of the link map. - Provide a function in ld.so to translate a link map into its TLS module ID, for gdb use. I'd be interested to hear from the glibc maintainers if they thought any of those were workable. The first is the ugliest, but most immediately usable, since dl_iterate_phdr is already available today. > I see multiple solutions (maybe first one enough?). > > * Hardcoding `#define errno (*__errno_location ())' into gdb. I'd rather not be specific to errno. > * Providing full custom TLS resolving for gdb - no glibc change needed. I think this is what I described above. > * Extending current glibc libthread_db for non-threaded inferiors. > (the patch sent before <20060908102235.GA31335@host0.dyn.jankratochvil.net>) Reasonable, except that it seems like a huge patch for limited gain. > * Merging the basic libpthread part for TLS resolving into glibc core > as nonthreaded glibc is using the TLS support for threading anyway. This could probably be made to work... > * Merging the whole libpthread to glibc, making libpthread just a stub, > forgetting there ever existed nonthreaded programs before, > the same way UP (vs. SMP) was forgotten. This would work :-) -- Daniel Jacobowitz CodeSourcery