From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15831 invoked by alias); 11 Aug 2004 17:12:04 -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 15824 invoked from network); 11 Aug 2004 17:12:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Aug 2004 17:12:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Buwdv-0006ib-GK for ; Wed, 11 Aug 2004 13:12:03 -0400 Date: Wed, 11 Aug 2004 17:12:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Fix for pending breakpoints in manually loaded/unloaded shlibs Message-ID: <20040811171203.GA4152@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <41191D71.60204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41191D71.60204@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00396.txt.bz2 On Tue, Aug 10, 2004 at 03:09:37PM -0400, Jeff Johnston wrote: > The following patch fixes a problem with breakpoints set in shlibs that are > manually loaded/unloaded by the program. What currently happens is that > pending breakpoints work properly for the first run of the program. On the > 2nd run, the resolved breakpoint(s) can end up at the start of the > breakpoint list and is marked bp_shlib_disabled. This is fine for a bit > and we reach the breakpoint again when the shared library is loaded. > However, when we unload the 2nd time, there is trouble. We eventually get > a shlib_event from the dlclose() and we attempt to remove the breakpoint to > step over it. Unfortunately, we try and remove all breakpoints and we end > attempting to remove a breakpoint that no longer exists (remember the > breakpoint for the shared library routine is now at the start of the > breakpoint list). We fail trying to remove the first breakpoint and end up > failing remove_breakpoints. We subsequently keep running into the > shlib_event breakpoint over and over again ad-infinitum. I couldn't quite follow your explanation of the problem, but FWIW your patch does make sense to me. Please check it for coding style problems; I noticed a lot of operators at the end of lines instead of the beginning of the next line. > +#if defined (PC_SOLIB) > + if (((b->type == bp_breakpoint) || > + (b->type == bp_hardware_breakpoint)) && > + breakpoint_enabled (b) && > + !b->loc->duplicate) You are just grabbing this from disable_breakpoints_in_shlibs, but the b->type check is not correct. Try (b->loc->type == bp_loc_hardware_breakpoint || b->loc->type == bp_loc_software_breakpoint) [Conceptually, you want any breakpoint which corresponds to a code address.] Can this code be commonized rather than duplicated? > + { > + char *so_name = PC_SOLIB (b->loc->address); > + if (so_name && > + !strcmp (so_name, solib->so_name)) > + { > + b->enable_state = bp_shlib_disabled; > + b->loc->inserted = 0; Are we guaranteed that the breakpoint is not inserted right now? This is the only place in breakpoint.c that changes the inserted flag directly other than initialization, insertion, and a hack for exec following. If you expect that the library has already been unmapped, so removing it would fail, please add a comment saying so. -- Daniel Jacobowitz