From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29444 invoked by alias); 11 Jan 2005 21:15:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29386 invoked from network); 11 Jan 2005 21:15:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Jan 2005 21:15:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0BLFqnW007076 for ; Tue, 11 Jan 2005 16:15:52 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0BLFpr28312; Tue, 11 Jan 2005 16:15:51 -0500 Received: from localhost.localdomain (vpn50-74.rdu.redhat.com [172.16.50.74]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j0BLFpBM007366; Tue, 11 Jan 2005 16:15:51 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id j0BLFjjh021521; Tue, 11 Jan 2005 14:15:45 -0700 Date: Tue, 11 Jan 2005 21:15:00 -0000 From: Kevin Buettner To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, drow@false.org, eliz@gnu.org Subject: Re: [RFA] Introduce solib_loaded observer Message-ID: <20050111141544.485ed645@ironwood.lan> In-Reply-To: <200501092258.j09MwImN012219@elgar.sibelius.xs4all.nl> References: <200501082314.j08NE6a1080151@elgar.sibelius.xs4all.nl> <20050109000104.GA1853@nevyn.them.org> <200501091305.j09D5FfO000568@elgar.sibelius.xs4all.nl> <20050109223732.GA3587@nevyn.them.org> <200501092258.j09MwImN012219@elgar.sibelius.xs4all.nl> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00073.txt.bz2 On Sun, 9 Jan 2005 23:58:18 +0100 (CET) Mark Kettenis wrote: > Date: Sun, 9 Jan 2005 17:37:33 -0500 > From: Daniel Jacobowitz > > On Sun, Jan 09, 2005 at 02:05:15PM +0100, Mark Kettenis wrote: > > > > Calling the observer after loading the symbols isn't possible. You > > can set "auto-solib-add" to 0, and then the symbols will never be > > loaded at all. So you'll always have to force loading the symbols > > from within your observer anyway (but you only have to do so for the > > threads library). From a code perspective the point where the > > notification is called is the most logical. And that way it's less > > likely that we see "auto-solib-add" related bugs ;-). > > At the same time, I worry that it's going to be confusingly > inconsistent - for instance, I would have expected turning off > auto-solib-add to prevent loading symbols for libpthread! Or at least, > loading of full symbols (all libthread_db on GNU/Linux really needs are > a couple of minsyms). > > We should try to be as consistent as possible. The current situation > is very inconsistent too: if you turn off auto-solib-add, you won't > get thread debugging support. It's true that for debugging support > you usually only need a few minimal symbols. I considered rolling my > own BFD-based lookup function, but I suspect that would result in a > serious performance hit because I'd lose the benefit of caching. > > I don't think "isn't possible" is accurate; there are only two callers > of update_solib_list, and one of them wants to read the symbols. That > could be pushed down into an argument to update_solib_list. Would that > be better? > > Because of the auto-solib-add issue I don't think it is, but given the > right arguments I think you can make me think differently. What to > the others think of this? IMO, setting auto-solib-add to 0 is useful in those situations where the application has a large number of shared libraries. Setting it to 0 will sometimes make it more expedient to debug such programs. I don't think that a GDB user wants to give up thread debugging when setting auto-solib-add to 0. Thus, I'm all in favor of Mark's current strategy. Mark, your patch is approved when you feel that useful discussion on this matter has ended. If Daniel convinces you that some other strategy is more appropriate, then that patch is preapproved so long as we don't give up the ability to debug threaded programs when auto-solib-add is 0. Kevin