Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice <ratmice@gmail.com>]

On Tue, Jul 26, 2011 at 12:53 PM, Tom Tromey <tromey@redhat.com> wrote:
> First of all, pinging Pedro -- I would greatly appreciate your
> commentary to help unblock this project.
>
> Tom> I propose a simple rule for the handling of ambiguous linespecs: a
> Tom> breakpoint whose argument is ambiguous will fire at all matching
> Tom> locations.  This rule has several properties that I consider desirable:
>
> Tom> * It is simple to explain to users
> Tom> * It is predictable
> Tom> * It is time-invariant
> Tom> * It is implementable ;-)
>
> This week while discussing this and other things on irc, we came up with
> a possible problem with the proposal: it interacts poorly with lazy
> debuginfo reading.
>

Another approach which would work with lazy debuginfo reading would be
to modify your original proposal with a continuation.  Change 'fire at
all matching locations'.  to 'find one or more matches stopping at the
first object file to provide a match'
then embedding a continuation into the breakpoint and a command to
'resume finding matches'.

It seems a more involved implementation than the 'permanent pending
breakpoint' option...

thus the interface would be something like:
break foo
resolve-next-match BPNUM
resolve-all-matches BPNUM

(or the appropriate `modify' variant)
and so on until finding the "foo" that is wanted, or object files are exhausted.

it doesn't hit: '* it is predictable' because its outcome is order
dependent, and the commands may need to be run number-of-matches
times.

i'm not really leaning in preference to either option, just wanted to
put the idea out there.