This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
- From: Matt Rice <ratmice at gmail dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 27 Jul 2011 22:18:43 -0700
- Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
- References: <20110505162855.GA2546@adacore.com> <m3oc3gx48l.fsf@fleche.redhat.com> <83bozgmhil.fsf@gnu.org> <m3oc2pxjds.fsf@fleche.redhat.com> <83k4dcd1bh.fsf@gnu.org> <m3r56bdoh9.fsf@fleche.redhat.com> <m362nmarbv.fsf@fleche.redhat.com> <m3hb68q0no.fsf@fleche.redhat.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.