From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16717 invoked by alias); 11 Aug 2004 15:58:03 -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 16708 invoked from network); 11 Aug 2004 15:58:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Aug 2004 15:58:03 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7BFw2e1012030 for ; Wed, 11 Aug 2004 11:58:02 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7BFw2a15749; Wed, 11 Aug 2004 11:58:02 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i7BFw2XP031873; Wed, 11 Aug 2004 11:58:02 -0400 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 0117D800025; Wed, 11 Aug 2004 11:58:02 -0400 (EDT) Message-ID: <411A4209.6020801@redhat.com> Date: Wed, 11 Aug 2004 15:58:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Fix for pending breakpoints in manually loaded/unloaded shlibs References: <41191D71.60204@redhat.com> <7494-Wed11Aug2004070352+0300-eliz@gnu.org> In-Reply-To: <7494-Wed11Aug2004070352+0300-eliz@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00394.txt.bz2 Eli Zaretskii wrote: >>Date: Tue, 10 Aug 2004 15:09:37 -0400 >>From: Jeff Johnston >> >>To fix this, I have added an observer for a new event: solib_unloaded. When >>update_solib_list discovers a shared library has been unloaded, it notifies all >>observers (initially this is just breakpoint.c). Breakpoint.c sets up an >>observer to find all breakpoints in the removed shlib and mark them as >>non-inserted and bp_shlib_disabled. This solves the problem. > > > Could you please explain why this complicated mechanism is needed to > fix this problem? Why cannot GDB directly mark the breakpoints when > the library is unloaded, instead of going the observer path? > Kind of damned if I do, damned if I don't :) I had talked over the problem with Andrew and he suggested the observer path as this is an event that other parts of gdb would be interested in knowing about. IMHO, the mechanism is rather elegant, extensible, and simple to use. Do you feel that this event isn't worthy of observation? -- Jeff J. > >>Index: doc/observer.texi >>=================================================================== >>RCS file: /cvs/src/src/gdb/doc/observer.texi,v >>retrieving revision 1.7 >>diff -u -p -r1.7 observer.texi >>--- doc/observer.texi 21 May 2004 16:04:03 -0000 1.7 >>+++ doc/observer.texi 10 Aug 2004 18:47:47 -0000 >>@@ -90,3 +90,8 @@ at the entry-point instruction. For @sa >> @value{GDBN} calls this observer immediately after connecting to the >> inferior, and before any information on the inferior has been printed. >> @end deftypefun >>+ >>+@deftypefun void solib_unloaded (struct so_list *@var{solib}) >>+The specified shared library has been discovered to be unloaded. >>+@end deftypefun >>+ > > > This part is approved (provided that the rest of the patch is > aproved). > > >>+/* Disable any breakpoints that are in in an unloaded shared library. Only > > ^^^^^ > A typo. > > >>+void >>+disable_breakpoints_in_unloaded_shlib (struct so_list *solib) >>+{ >>+ struct breakpoint *b; >>+ int disabled_shlib_breaks = 0; >>+ >>+ /* See also: insert_breakpoints, under DISABLE_UNSETTABLE_BREAK. */ >>+ ALL_BREAKPOINTS (b) >>+ { >>+#if defined (PC_SOLIB) > > > I think this #ifdef should be outside the loop: why loop at all if we > do nothing inside the loop body? >