Re: [RFA] unexpected multiple location for breakpoint

[Joel Brobecker <brobecker@adacore.com>]

[sorry for the delay]

Thanks, everyone, for participating in the discussion! Hey Daniel,
always good to read from you :-).

> On Fri, Nov 26, 2010 at 09:29:42AM -0800, Joel Brobecker wrote:
> > 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.
> 
> I don't think that's right.  This is a lexical relationship; it
> doesn't imply any relationship at the PC level.  But I'm not sure it's
> what you meant, either, since this:
> 
> > 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
> 
> illustrates a counter-example.
> 
> I'm a bit confused, though; what sort of example produces this
> structure?  Are single-line blocks involved (e.g. "if (a) { x; }" all
> on one line)?

The example above is purely hypothetical. I think it might happen
perhaps because of code re-ordering because of optimization.

> I would prefer GDB not make any decisions based on "lowest address";
> between inlining, basic block reordering, et cetera, it doesn't mean
> much.

So, if I understand you well, you suggest that we rework a bit the
"contained-in" elimination loop to avoid lowest-address assumptions.
If 2 different PCs are inside the same block, then keep the lowest
address.  If PC1 is in BLOCK1 and PC2 in BLOCK2, and BLOCK2 is contained
in BLOCK1, then PC2 should be discarded, even if PC2 > PC1. (and
if the blocks are distinct, then keep both PCs).

-- 
Joel