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: Tom Tromey <tromey at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 26 Jul 2011 13:53:15 -0600
- 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>
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.
Right now there are several patches (and planned patches) to make
debuginfo reading lazier: my lazy reading patch for new inferiors,
Sergio's work, and Gary and Paul both have work in this area too. These
all rely on the idea that, generally, loading a new .so doesn't mean
that we must necessarily read its debuginfo.
However, with the plan as proposed, GDB will in most cases become much
less lazy-capable. While the proposal addresses this in part by letting
users specify breakpoint locations more precisely, this will not happen
by default -- "break main" will still mean loading all the debuginfo for
everything gdb sees.
So, a slightly different approach to solving this would be to make
breakpoints capture their location set at the "point of resolution" --
either immediately, or for a pending breakpoint, the first time it hits.
Then, provide some additional syntax to make a "permanently pending"
breakpoint.
This approach would provide efficiency by default ("break main" would
typically resolve to a single location, not requiring any extra
debuginfo reads in the future) with an option for a more dynamic
approach for those circumstances requiring it.
I am not completely sold on this, but I wanted to float the idea for
comments.
I think this might imply some cleanup of the current breakpoint
re-setting approach.
Tom