Re: some questions about ranged breakpoints

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Tom> What should actually happen here?

Pedro> I think we should remove the assertion, and have each location map to a
Pedro> hardware accelerated ranged breakpoint, instead of assuming there can
Pedro> be only one.  This isn't much different from creating a regular
Pedro> (non-range) hardware breakpoint that ends up mapping to more than
Pedro> one location.

Ok, that makes sense, but unfortunately I think it yields other weird
behavior.  The problem is that you must somehow pair start and end
locations; you might even see more of one than the other.

I thought that pairing could perhaps be done by sorting the addresses
and, for each address in the first list, choose the nearest greater
address from the second list.  However, my worry with any heuristic like
this is that a re-set could cause the breakpoint to change in an
unforseen way, yielding wrong results for the user.

Also the parsing is a pain when you have multiple matches.
Consider the difference between a relative linespec (break-range
file.c:73, +5) and an absolute one (break-range file.c:73, file.c:78).
We don't know before parsing whether a linespec is relative.
So, I think we have to reparse the second linespec in the context of
each result from the first linespec, then eliminate dups... gross, but I
guess doable.

Tom