From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15511 invoked by alias); 9 Sep 2011 19:33:09 -0000 Received: (qmail 15500 invoked by uid 22791); 9 Sep 2011 19:33:07 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SARE_SUB_IMPROVE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Sep 2011 19:32:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p89JWi8i014726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Sep 2011 15:32:44 -0400 Received: from host1.jankratochvil.net (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p89JWgC9006191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Sep 2011 15:32:44 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p89JWfDF023946; Fri, 9 Sep 2011 21:32:41 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p89JWelU023940; Fri, 9 Sep 2011 21:32:40 +0200 Date: Fri, 09 Sep 2011 19:41:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org, Daniel Jacobowitz Subject: Re: [RFA] Improve performance with lots of shared libraries Message-ID: <20110909193239.GA23130@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109091609.31737.pedro@codesourcery.com> <201109091553.22390.pedro@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00168.txt.bz2 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? Any other ideas for restrictions? Thanks, Jan