Re: [RFA] unexpected multiple location for breakpoint

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 29 Dec 2010 09:48:41 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > > If this is a bug, then the only solution I can think of is inserting
> > > a breakpoint at *every* instances of line 53, regardless of
> > > lexical-block relationships.
> > 
> > When would that be worse than what we have now?
> 
> I worry about the effect at -O0. It is common to see the same source
> line being split across the code.  For instance, with conditional
> loops, the condition evaluation is often placed at the end of the
> loop, and its code is associated to the initial line.

Are you saying that GCC does that under -O0?  I'd be surprised.  But I
realize that it does that for higher optimization levels.  Still, my
question is how would it be worse to have the inferior stop several
times through the loop than not stop at all?

> Note that we also have the following explicit comment in the code:
> 
>   /* For optimized code, compiler can scatter one source line accross
>      disjoint ranges of PC values, even when no duplicate functions
>      or inline functions are involved.  For example, 'for (;;)' inside
>      non-template non-inline non-ctor-or-dtor function can result
>      in two PC ranges.  In this case, we don't want to set breakpoint
>      on first PC of each range.  [...] */
> 
> For the record, attached is the patch that I used.  It was written on
> top of the initially proposed patch (in this thread), but just purely
> for convenience. The piece that checks the next entry is to avoid
> inserting a breakpoint on 2 blocks if the two blocks are consecutive.

That's fine, and I think it will take care of the most blatant
offenders.