From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17020 invoked by alias); 13 Sep 2006 03:45:27 -0000 Received: (qmail 17012 invoked by uid 22791); 13 Sep 2006 03:45:27 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Sep 2006 03:45:21 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 32BA448CC27 for ; Tue, 12 Sep 2006 23:45:19 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28757-02-3 for ; Tue, 12 Sep 2006 23:45:19 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id E347A48CBE1 for ; Tue, 12 Sep 2006 23:45:18 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2C12547F00; Tue, 12 Sep 2006 20:45:18 -0700 (PDT) Date: Wed, 13 Sep 2006 03:45:00 -0000 From: Joel Brobecker To: gdb@sources.redhat.com Subject: Re: (linux/threads) Interesting side-effect of "auto-solib-add 0" Message-ID: <20060913034518.GH24293@adacore.com> References: <20060913002712.GF24293@adacore.com> <20060913003347.GA24280@nevyn.them.org> <20060913004720.GG24293@adacore.com> <20060913022113.GA26971@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060913022113.GA26971@nevyn.them.org> User-Agent: Mutt/1.4i 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/msg00070.txt.bz2 > Ah, simple: they're not there. Take a look at the ps_* routines in > proc-service.c. In particular, ps_pglobal_lookup. It's not at all > surprising that you couldn't find them; this is a very rare library > interface. The shared library actually has undefined symbols which > must be satisfied by GDB. Ah ha, I see! I didn't realize it was using undefined references... I've been used to seeing callbacks... > Do you want to stick a comment in linux-thread-db.c somewhere > suggesting a look over there too? Absolutely, might be useful to someone else. I'll do that tomorrow. > The technical alternative, if you want to implement it, would be to > always load symbols for libpthread. What do you think? We don't even > really need debugging symbols - just the minimal (ELF) symbol table. I have been thinking about that, but there were several little factors that made me reconsider. The one that I didn't like the most was the fact that the only way I could see to detect the pthread library being loaded is by looking at its name. It doesn't feel very elegant to have to search for "/libpthread.so" or somesuch in GDB. I don't know very well how GNU/Linux distributions are made, but couldn't that library be named libpthread-1.8.0.so, for instance, making its identification harder? At one point, I considered the idea of detecting libpthread.so, and printing a warning saying that, because auto-solib-add has been deactivated, thread support hasn't been enabled. But that's almost no less work than the above, so pointless. In the end, because I wasn't able to produce any unexpected behavior except maybe lack of thread support, and given the probable little number of times this capability is used (I'm guessing, though), it didn't seem worth the effort. I do realize, however, that it shouldn't be too much work, though. I'm open to both alternatives: 1. Enhance GDB 2. Document the limitation (Eli also agreed with the idea) -- Joel