Re: [RFA take 4] Allow setting breakpoints on inline functions (PR 10738)

[Doug Evans <dje@google.com>]

On Wed, Feb 15, 2012 at 1:47 AM, Gary Benson <gbenson@redhat.com> 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.

>> 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.  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. :-)]