From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4476 invoked by alias); 12 Sep 2011 12:18:04 -0000 Received: (qmail 4389 invoked by uid 22791); 12 Sep 2011 12:18:00 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_00,SARE_SUB_IMPROVE X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Sep 2011 12:17:44 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R35SJ-0002eA-KC from pedro_alves@mentor.com ; Mon, 12 Sep 2011 05:17:43 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Sep 2011 13:17:41 +0100 From: Pedro Alves To: Jan Kratochvil Subject: Re: [RFA] Improve performance with lots of shared libraries Date: Mon, 12 Sep 2011 12:44:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: gdb-patches@sourceware.org, Daniel Jacobowitz References: <20110909193239.GA23130@host1.jankratochvil.net> In-Reply-To: <20110909193239.GA23130@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109121317.40222.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00186.txt.bz2 On Friday 09 September 2011 20:32:40, Jan Kratochvil wrote: > On Fri, 09 Sep 2011 16:53:22 +0200, Pedro Alves wrote: > > Not according to > > Oops, I read it but ... > > On Fri, 09 Sep 2011 17:09:31 +0200, Pedro Alves wrote: > > ... and I don't think that's entirely true. Yes, GDB will stop > > trying to resolve the spec to a symbol, but at every event gdb will > > still re-set the breakpoint locations. If the new library has > > the _same_ file:lineno compiled in (e.g., we put a breakpoint > > on a c++ template in a header, or an inline function that is > > also used by new library), then we should be getting new locations in > > the new shared library, today. > > I would not state it so optimistically, in my experience the watchpoints to > inlined functions (PR 10738) and templates (file:line will break just at the > one instance kind, not all of them) do not work much. But I agree the design > of extensions should not block fixes of these issues. > > Maybe the conditionals for "breakpoint can extended into new objfiles" could > be extended so that most common most simple practical use cases do not get > affected. > > For example if the breakpoint is function-name kind (not [file:]line), exinst > placement has single location, it is not inlined instance and it is not > template instance? Not sure that's a good restriction. :-( Inline functions can have an out-of-line copy too. If you "break my_inline_function", and end up with only a breakpoint at the out-of-line copy (there were no inline expansion in the program yet), and then later the program loads a DSO that does have inline expansions of the same function, you'd want your breakpoint to now gain locations for those inline expansions. I think Tom's branch is supposed to make this case work that way. > Any other ideas for restrictions? Only one, when Tom's work is done, make breakpoints have a "final" property (meaning, "stop adding locations for this breakpoint") for user breakpoints, and automatically mark some internal breakpoints we know can't have more than one location with that flag. Breakpoints on addresses ("b *FOO") would have the "final" property implicitly as well. If all the breakpoints in the table are "final", then we don't need to track shared library loads. -- Pedro Alves