Re: GDB 7.4 branching status? (2011-11-23)

[Jerome Guitton <guitton@adacore.com>]

Joel Brobecker (brobecker@adacore.com):

> > First, I think having too many locations is better than having too few.
> > With too many, at least the user can disable some.  With too few,
> > whoops, gdb isn't doing as asked.
> > 
> > Second, at least initially the heuristic only has to perform as well as
> > what gdb already does.
> 
> I agree.
> 
> Right now, we're stuck between a rock and a hard place. So it's
> more of a matter of deciding which approach matches our goals
> the most. If we go by the principles above, the simpler heuristic
> seems the way to go. It introduces an apparent regression for Ada,
> but I don't see a simple way around it that does not sacrifice
> a little bit of the principles above. We're just going to have
> to call it a limitation.


Well, having a regression for Ada defeats the second principle, IMHO :)
And I think that it is not Ada-specific at all actually; to reproduce
the problem in C++, you just need to have a couple of
templates/inlined functions in a header and have them instanciated in
different source files.

What about having the same heuristics as expand_line_sal used to have for
this kind of issue? At least we would have the exact same behavior as
before...

You reported that this heuristic was the following:

 The approach they use is to select exact matches first. And then, if there
 are no exact matches, then select exact matches for the first line above the
 selected line.

This heuristic is flawed as well, but the other that have been proposed
so far have some issues themselves. So maybe we should just start with
what we already have before trying to find a clever solution?