Multiple locations vs. watchpoints.

[Andrew Cagney]

> I don't think we should do that.  I think we should leave things as
> they are now, namely, that "break foo" means the function foo in the
> _current_ module, be that foo.c or bar.c.  For the other, the user is
> required to type "break bar.c:foo".
> 
> In C++ and other OO languages, this is different, but in C we
> shouldn't introduce confusion, IMHO.  Someone who debugs a C program
> doesn't expect to get a breakpoint on a completely different function.

Yes, it also applies to OO languages.  The current SAL, frame, ... 
specify the scope that is used to qualify the breakpoint / watchpoint.

>> It watches whatever *bar would print, which is one of them.  No easy way to
>> get at the other or describe the ambiguity.  I wonder once again whether the
>> two-level scheme is really correctly designed; but I have no better ideas.

I think there are two largely independant problems here:

- two level breakpoint / location table
this assumes that something like "rbreak <pattern>" just creates 
multiple breakpoints (which are then broken down into locations)

- CLI operations and changes that provide greater flexability in 
manipulating the breakpoint table (rdelete, renable, breakpoint groups, 
...?)

and personally I'd be completly ignoring the second one for the moment.

enjoy,
Andrew