From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15609 invoked by alias); 15 Feb 2012 09:48:14 -0000 Received: (qmail 15598 invoked by uid 22791); 15 Feb 2012 09:48:11 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from gbenson.demon.co.uk (HELO gbenson.demon.co.uk) (80.177.220.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 09:47:56 +0000 Date: Wed, 15 Feb 2012 12:17:00 -0000 From: Gary Benson To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFA take 4] Allow setting breakpoints on inline functions (PR 10738) Message-ID: <20120215094752.GA2712@redhat.com> Mail-Followup-To: Doug Evans , gdb-patches@sourceware.org References: <20120213184700.GA31170@redhat.com> <20120214090204.GA2839@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 2012-02/txt/msg00296.txt.bz2 Doug Evans wrote: > On Tue, Feb 14, 2012 at 1:02 AM, Gary Benson wrote: > > Doug Evans wrote: > > > On Mon, Feb 13, 2012 at 10:47 AM, Gary Benson wrote: > > > > This patch makes GDB able to set breakpoints on inlined > > > > functions. > > > > > > > > This version of the patch has been updated to fix the issues > > > > Jan pointed out with the last version. > > > > > > > > This patch bumps the version number of the .gdb-index to 6, > > > > but it does not remove any of the backwards compatibility code > > > > which I would prefer to do as a separate patch. > > > > > > I agree support for older versions should be a separate patch. > > > However this patch doesn't do that (it removes current > > > acceptance of older versions of the index). > > > > That's correct.  The older versions do not contain partial symbols > > for inlined functions.  If GDB were to be run on a file with an > > older versioned index without rejecting it then the ability to set > > breakpoints on inlined functions would silently fail. > > "silently fail" as in "work *worse* than it did in previous gdb > versions"? It wouldn't work *worse* than previous gdb versions--it would be the same--but it would work worse than itself. You would have the situation where an optimization was causing functionality to be lost, and that doesn't seem right to me. > While it may seem like it's always a win to just discard the index > to get new functionality, I'm not sure all users would agree with > that in all situations. If gdb 7.4 startup takes 5 seconds and gdb > 7.5 startup takes 45 seconds on the same binary, and our response to > their complaint is that they have to rebuild the index, I'm not sure > I'd be comfortable with that. Especially if, for example, they're, > say, debugging a core file and can't use the new functionality > anyway. ***OTOH***, if there is a functional *regression* (as > opposed to a speed regression) then I'd be much more comfortable > with discarding the index. > [to repeat my question above, for clarity's sake: Is there a > functional regression if we don't discard the index?] > OTOOH, 1/2 :-), why must there be a functional regression? [as > opposed to the absence of a new feature or capability] I guess it depends on how you define a functional regression. If you compare GDB as it is now, GDB with this patch, and GDB with this patch minus the index version, the functionality would look like this: | GDB GDB GDB | now ver bump no ver bump -------------------------+----------------------------------- | Break on inline funcs | no yes yes in files without index | | Break on inline funcs | no yes no in files with old index | (ignored) | Break on inline funcs | no yes yes in files with new index | GDB's behaviour is inconsistent if you don't rejecting the old index files. That seemed like a bad thing to be introducing. > One could support the old version for a release or two, and print a > warning when older versions are encountered. I wondered about this myself, though it was pointed out to me that printed warnings often get lost in the noise. > The user's build procedure may involve building the index in a way > that is not easily updated in a timely manner. Thus all the speed > improvements are (at least temporarily, but for a long enough time to > be troublesome) wiped out simply by using a *newer* version of gdb. > And that makes me uncomfortable. How would it be if there the default behaviour was be to reject old indexes (as the patch does now) but with the addition of a flag ("maint set allow-old-gdb-indexes" perhaps?) that would allow users in this particular situation to get around it? That way, our response to complaints can be "rebuild the index *or* use this flag (which by the way will lose you such and such a functionality)" Inconsistent behaviour doesn't seem so bad if the user asked for it. Cheers, Gary -- http://gbenson.net/