Re: [RFA] unexpected multiple location for breakpoint

[Joel Brobecker <brobecker@adacore.com>]

> +     We start from last to first in our list of PCs, in order to take
> +     care of the case where 2 entries are associated to the same block:
> +     When we have one or more lines in the same block, we want to stop
> +     at the first instruction of that line, hence we want to eliminate
> +     the highest address.  */
> +
> +  for (i = ret.nelts - 1; i >= 0; i--)
>      if (blocks[i] != NULL)
> -      for (j = i+1; j < ret.nelts; ++j)
> -	if (blocks[j] == blocks[i])
> +      for (j = 0; j < ret.nelts; ++j)
> +	if (j != i && filter[j] && contained_in (blocks[i], blocks[j]))

About this patch - Doug and I had a quick talk about on IRC, and one
of the things I said was that the items in the SAL list should be
ordered by ascending PC.  I'm not sure that's true anymore. This is
true within a linetable, but the array is a collection of entries
for potentially more than 1 unit. So that assumption was wrong.

However, I wonder if that makes any difference at all in our case:
If we have a "contained-in" relationship between two entries, then
the first of the two entries necessarily has a lower PC than the
second one.

The one scenario that Doug and I identified which my patch probably
does not handle well is the following case:


     block1:
         block2:
             .line N
         end block2
         .line N
     end block1

If the user tries to break on line N, what should we do? With the
current approach, we expect GDB to select the second entry only.
This is not optimal, because we probably should try to break on
the entry with the lowest address if we can.  But just breaking
on the first one runs the risk of never stopping - this may happen
if entry in block2 is conditional.

So we determined that we should select both line entries in that case.
This is achieved by reducing the iteration range for the inner for loop
to [0, i[.

I will work on submitting a patch with that change and additional
comments ASAP.

-- 
Joel