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

[Tom Tromey <tromey@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