From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2685 invoked by alias); 7 Dec 2004 00:15:27 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2652 invoked from network); 7 Dec 2004 00:15:19 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Dec 2004 00:15:19 -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 iB70FJMp024589 for ; Mon, 6 Dec 2004 19:15:19 -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 iB70FEr19500; Mon, 6 Dec 2004 19:15:14 -0500 Received: from localhost.localdomain (vpn50-35.rdu.redhat.com [172.16.50.35]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iB70FDGE006971; Mon, 6 Dec 2004 19:15:14 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB70F88m015269; Mon, 6 Dec 2004 17:15:08 -0700 Date: Tue, 07 Dec 2004 00:15:00 -0000 From: Kevin Buettner To: Randolph Chung Cc: gdb@sources.redhat.com Subject: Re: [RFC] what to do with hpux-specific solib features Message-ID: <20041206171507.3c7c0d51.kevinb@redhat.com> In-Reply-To: <20041206230105.GR6359@tausq.org> References: <20041206230105.GR6359@tausq.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00037.txt.bz2 On Mon, 6 Dec 2004 15:01:05 -0800 Randolph Chung wrote: > There are a bunch of features that are only implemented currently for > the SOM and pa64 solib handlers for HP-UX. Do we want to support these > elsewhere? do we want to get rid of them? > > e.g. > Dynamically-linked library events may be caught: > catch load - loads of any library > catch load - loads of a particular library > catch unload - unloads of any library > catch unload - unloads of a particular library This provides a more fine grained way of stopping on particular events than "set stop-on-solib-events", right? It seems to me that this functionality might occasionally be useful elsewhere. However, I wouldn't let that hold you up if you're attempting to convert over to the generic solib machinery. It seems to me that such functionality could be implemented in a generic fashion (by noticing when a shared library is added to or removed from the global list), and as such, could be added back at any time. Kevin