From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 956 invoked by alias); 15 Feb 2012 20:06:48 -0000 Received: (qmail 945 invoked by uid 22791); 15 Feb 2012 20:06:47 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 20:06:34 +0000 Received: by vbip1 with SMTP id p1so1309750vbi.0 for ; Wed, 15 Feb 2012 12:06:33 -0800 (PST) Received: by 10.220.152.146 with SMTP id g18mr15205324vcw.30.1329336393543; Wed, 15 Feb 2012 12:06:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.152.146 with SMTP id g18mr15205316vcw.30.1329336393474; Wed, 15 Feb 2012 12:06:33 -0800 (PST) Received: by 10.220.162.7 with HTTP; Wed, 15 Feb 2012 12:06:33 -0800 (PST) In-Reply-To: <20120215094752.GA2712@redhat.com> References: <20120213184700.GA31170@redhat.com> <20120214090204.GA2839@redhat.com> <20120215094752.GA2712@redhat.com> Date: Wed, 15 Feb 2012 20:14:00 -0000 Message-ID: Subject: Re: [RFA take 4] Allow setting breakpoints on inline functions (PR 10738) From: Doug Evans To: gdb-patches , gbenson@redhat.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlcY9Du3kihsKXlpf4O3TDenjIqPM6aATqTuNCba0Ksov68TtuHIDHbfvf8LZMiyqeLSMEP3+qg6+kQwffkIlv3BnXZslFvz12r903fDRbSio1n8DAgT4cYgYJYwf4xUTQT7CbRHxiFkBdla8NbxIsRm8BjjA== 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/msg00311.txt.bz2 On Wed, Feb 15, 2012 at 1:47 AM, Gary Benson wrote: > GDB's behaviour is inconsistent if you don't rejecting the old index > files. =A0That seemed like a bad thing to be introducing. Absent a notification to the user and ability to control it, sure. But I think we can come up with something appropriate. >> 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. One can debate this forever. :-) >> The user's build procedure may involve building the index in a way >> that is not easily updated in a timely manner. =A0Thus 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? =A0That 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)" =A0Inconsistent > behaviour doesn't seem so bad if the user asked for it. IWBN if one could do "gdb my-binary-with-older-index" (as opposed to, e.g., "gdb ; maint set ... ; file my-binary-with-older-index", or the equivalent with -x/-ex foo, and setting the flag in ./.gdbinit won't work). That pretty much means passing gdb an option ("gdb --use-old-index my-binary" or some such). At Google we've added --disable-gdb-index as an escape hatch against broken indices. I'm happy to replace it with something that will do the same thing. As for what the default behaviour should be, I don't have a strong enough opinion to want to defend it. I can easily enough change it here if desired. [Not something unfamiliar to Redhat. :-)]