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

Pedro Alves
2011-08-02T15:33:24Z

On Tuesday 26 July 2011 20:53:15, Tom Tromey wrote:
> First of all, pinging Pedro -- I would greatly appreciate your
> commentary to help unblock this project.

I'm very sorry for the delay in responding to this. It turns
out the world didn't stop when I went on vacation, for some
unknown reason, and I've took a long time to catch up... I
wanted to read the whole discussion and think at least a bit
before replying...

I'm sold on going your proposed direction, and forgetting the
3-level breakpoints approach.

I believe it provides a similar experience to what TotalView
users are used to, FWIW.

>
> 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

Okay, agreed.

> Tom> * It is implementable ;-)

:-) I think breakpoint_ops'ing all things would make 3-tier
easier, but that's moot now.

>
> 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.

I don't think it's a good idea to confuse the user interface
design with some optimizations. I'd rather we have "correct"
before "optimized". "unsurprising" before "super fast".

> Right now there are several patches (and planned patches) to make
> debuginfo reading lazier: my lazy reading patch for new inferiors,

I never replied to your patch, but my reaction was that it is
probably breaking breakpoints in the new inferiors today,
even without any linespec/multi breakpoints work. Wouldn't
e.g., making debug info reading smarter (the sharing of
objfiles between inferiors work/idea?) mostly dispense that
approach?

It's not just user breakpoints that worry me with simply avoiding
debug info altogether with some per-inferior flag, rather than
making it depeng on need/request. E.g., activating thread
library debugging usually needs at least minimal symbols.
Another example, GDB currently only invites the remote end to ask if
it wants GDB to resolve some symbols (qSymbol) after loading the
objfile. With a lazy scheme, we should let the remote end know (send
it a qSymbol) there's potentially new symbols available, even if
we haven't yet read the debug info. If the remote end replies
with a request, we can read the debug info then.

> 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'm not sold on this either. One could do something similar,
but leavy the default the way around -- have a new "final"
property/option of breakpoints --- once it's spec resolves,
it no longer gets locations auto-added, and have the user
request for final'ness explicitly. The "final" property
does not need to be final itself, it could be toggleable.

What I don't think I have seen addressed is how the proposal
interacts with multi-exec. E.g, suppose I have program foo
loaded once (one inferior) and program bar loaded twice (two
inferiors). I have one of the bar inferiors in focus,
and I do "b main". How many locations does this resolve to?
One, two, or three? Currently, it resolves to two.

>
> I think this might imply some cleanup of the current breakpoint
> re-setting approach.

--
Pedro Alves