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

[Eli Zaretskii <eliz at gnu dot org>]

> From: Tom Tromey <tromey@redhat.com>
> Date: Fri, 01 Jul 2011 10:39:00 -0600
> 
> Here is my proposal for how to handle ambiguous linespecs.

Thanks.

> I think I/T sets are also a good idea here

What is an "I/T set"?

> Tom> 6. Set a breakpoint that has a match in the inferior.  Then the inferior
> Tom>    loads a .so to make the linespec ambiguous.
> 
> Add new locations to the breakpoint.

How about alerting the user to this effect, giving them an opportunity
to narrow the scope of the breakpoint?  We could have this as an
optional behavior, but IMO if the breakpoint was unambiguous when I
set it, I would like such an alert by default, because it could be
that I knew what I was doing, and GDB might be defeating me now.

OTOH, if the new-and-improved linespec will allow me to be specific
about this use case (i.e. I don't want any other locations be added),
perhaps this is not an issue.  On the third hand, I could be
forgetting something when I specify the breakpoint, and still be
surprised.

>   modify breakpoint N location LINESPEC

I think this kind of command is necessary not only for the use case
which led you to conclude that it's needed.  We need this to let the
user re-specify location based on dynamically changing environment of
the debugging session: shared libraries being loaded and unloaded,
inferiors starting and exiting, etc.

(As for the command name, I'd suggest "location N LINESPEC", btw.)

I would also recommend an option to stop and suggest such changes
whenever any event happens that would normally trigger addition of
another location, but _before_ such a location is added -- e.g.,
because putting a breakpoint on some locations has undesirable side
effect, like in embedded systems.

IOW, we should give the user more control on the precise linespec,
including when the original linespec turns out to be different from
what it was when typed.

You say nothing about watchpoints.  Will they also use the same
infrastructure?

> I welcome contrasting proposals

Sorry, I don't have any ;-)

Thanks again for working on this.