From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29112 invoked by alias); 1 Mar 2003 02:16:43 -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 29104 invoked from network); 1 Mar 2003 02:16:43 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by 172.16.49.205 with SMTP; 1 Mar 2003 02:16:43 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h212Ggg7011099 for ; Fri, 28 Feb 2003 18:16:42 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 28 Feb 2003 18:16:38 -0800 Received: from apple.com (inghji.apple.com [17.201.22.240]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h212GbQ26508 for ; Fri, 28 Feb 2003 18:16:37 -0800 (PST) Date: Sat, 01 Mar 2003 02:16:00 -0000 Subject: Re: deferred breakpoints Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Ingham To: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <1046355813.623.ezmlm@sources.redhat.com> Message-Id: X-SW-Source: 2003-03/txt/msg00000.txt.bz2 Kris, That sounds fine. PB does that for all the GUI type breakpoints (where the user actually clicks in a source window gutter somewhere). It goes a little further, because it also knows what shared library(s)/executable that file got build into, so it just waits for that to get loaded before inserting the breakpoint. One thing that you will have to be careful about when you are getting the GUI to stop for shared library events is that when the user does a "next" over a function that causes a shared library load, you are probably going to lose control of the inferior and set it running. The reason for this is that completing the "next" over the function is implemented by a special breakpoint (step-resume). However, when the target "really" stops, it deletes the step resume breakpoints (since you might step again, and they don't stack). However, stopping when you have stop-on-solib-event set to "true" is considered a "real" stop - as indeed it is since the user regains total control. So then when the GUI resumes, the step-resume breakpoint gets deleted, and there is nothing to stop it anymore, so it just continues. This doesn't happen often, but it is really annoying when it does... I worked around this by adding a solib-step-bp and a solib-finish-bp, and by "transferring" the step-resume breakpoint to one of these as appropriate, you catch again. I am not sure this is the right way to do it, because you run the risk of stranding these breakpoints (as you would with the step-resume breakpoints...) Might be better to have an "I promise all I am going to do is continue" type flag and when you hit the solib and stop, you remind yourself NOT to remove the step-resume breakpoints. You will also have to remember to hold onto the stepping range so you will step to the end of the source line (the step-resume breakpoint in on the return from the called function which is often not the line end...) Hope this helps, Jim On Thursday, February 27, 2003, at 06:23 AM, gdb-digest-help@sources.redhat.com wrote: > From: Kris Warkentin > Date: Wed Feb 26, 2003 8:51:54 AM US/Pacific > To: Jason Molenda > Cc: gdb@sources.redhat.com > Subject: Re: deferred breakpoints > > > Looks like it might be a moot point. Deferred breakpoints are > implementable > from the ide side of things just by keeping an internal list of > breakpoints > and then attempting to apply them whenever there is a shlib event. > Eclipse > keeps breakpoints associated with libs and apps in its metadata so they > persist across invocations so no special wiring in gdb will be > required. > > cheers, > > Kris > -- Jim Ingham jingham@apple.com Developer Tools Apple Computer