From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21699 invoked by alias); 10 Jul 2003 16:33:52 -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 21689 invoked from network); 10 Jul 2003 16:33:51 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 10 Jul 2003 16:33:51 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E8B1C2B6E; Thu, 10 Jul 2003 12:33:51 -0400 (EDT) Message-ID: <3F0D956F.9040300@redhat.com> Date: Thu, 10 Jul 2003 16:33:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Molenda Cc: Kris Warkentin , "Gdb@Sources.Redhat.Com" Subject: Re: [rfc] Print solib events in mi-mode References: <062401c34590$97cd09b0$0202040a@catdog> <55757AD0-B24D-11D7-9281-000393D457E2@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00134.txt.bz2 > We handled this problem by creating a new breakpoint command, "future-break" (short: "fb", done in MI as "-break-insert -f ..."). This pushes the logic down in to gdb. On the one hand, it's expensive to have gdb trying to set this breakpoint for every shared library that comes in (when you have a lot of big shared libraries like we do on MacOS X), but at the same time if the IDE is responsible for setting breakpoints in shared libraries then you'll have to stop on each solib add event to set those breakpoints before anything runs... > > You can see all of this in the above sample; breakpoint #1 was a file:line breakpoint, which was in SKTGraphic.ob. When SKTGraphic.ob was paged in (this is a project using ZeroLink, so each source file is a separate objfile, pulled in at run-time as needed), the breakpoint was set by gdb. > > > > The future-break patches were posted at least once in the past along with the save-breakpoints command; I can find a URL ref if anyone cares. Yes, Tom Tromey observed: http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html > Klee> The 'future-break' command allows one to specify a breakpoint > Klee> that starts off as 'shlib_disabled' instead of generating an > Klee> error if it can't be set immediately. > > Klee> I'm not entirely happy with the future-break command, and > Klee> particularly with its interaction with the save-breakpoints > Klee> mechanism (if you set a breakpoint that is in a shared library > Klee> after shared libraries have been loaded, you have to remember to > Klee> use the future-break command, not the break command). > > Doesn't this mean that programs like Insight would be best advised to > *only* set future breakpoints? In that case let's just add the > functionality directly to the existing breakpoint commands. enjoy, Andrew