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 05:31:51 -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:
>
> I am not completely sold on this, but I wanted to float the idea for
> comments.
I guess, a case where this one acts oddly is,
there is a currently unambiguously resolvable function,
which will become ambiguous on future shared library processing.
in that case you need a way to force a pending breakpoint.
also because outside of dlopen there is generally no prompt in between
shared library processing, usage of a 'permanent pending breakpoint'
will cause debug-info for all shared libraries to be processed in
between run and the gdb prompt.
it doesn't seem like it is incompatible with foo.so:function_of_doom
style breakpoints
that could be used to mitigate the chewing through all debug-info too.
it doesn't gracefully/effortlessly handle ambiguous breakpoints like
the previous solution, but to me that isn't that big of an issue, as
long as there is a way to handle them when they are encountered.
That there is some way to resolve an ambiguous location to the one I
want gdb to stop at, rather than that it manages to resolve all
ambiguous linespecs.
Shrug.