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

[Doug Evans <dje@google.com>]

On Tue, Feb 14, 2012 at 1:02 AM, Gary Benson <gbenson@redhat.com> wrote:
> Hi Doug,
>
> Doug Evans wrote:
>> On Mon, Feb 13, 2012 at 10:47 AM, Gary Benson <gbenson@redhat.com> wrote:
>> > Hi all,
>> >
>> > 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"?

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]

One could support the old version for a release or two, and print a
warning when older versions are encountered.

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.