From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22546 invoked by alias); 16 Feb 2012 10:38:39 -0000 Received: (qmail 22420 invoked by uid 22791); 16 Feb 2012 10:38:37 -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; Thu, 16 Feb 2012 10:37:54 +0000 Date: Thu, 16 Feb 2012 10:41:00 -0000 From: Gary Benson To: Doug Evans Cc: gdb-patches Subject: Re: [RFA take 4] Allow setting breakpoints on inline functions (PR 10738) Message-ID: <20120216103751.GA3378@redhat.com> Mail-Followup-To: Doug Evans , gdb-patches References: <20120213184700.GA31170@redhat.com> <20120214090204.GA2839@redhat.com> <20120215094752.GA2712@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/msg00321.txt.bz2 Doug Evans wrote: > 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.  That 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. Ok. > > > 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. :-) Well, quite :) > > > 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. > > 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. :-)] Ok, so my plan is to implement an --allow-incomplete-gdb-index option that will turn on support for version 4 and 5 indexes. I am unsure as to whether to add printed warnings, but I'm leaning towards not having warnings in either configuration. With the default setting GDB will work correctly, but may possibly be slow which would be the (admittedly not very direct) trigger for the user to investigate. With the option supplied I assume the user knows what they're doing, so they don't need pestering! I like the *idea* of warning users that their .gdb-index sections are being skipped, but I think of the case where somebody uses a new GDB on an older version of Fedora (say) being flooded with warning messages about every single shared library their program is linked to. Cheers, Gary -- http://gbenson.net/