Re: [PATCH, gdb6.8] -break-list doesn't list multiple breakpoints

[Vladimir Prus <ghost at cs dot msu dot su>]

On Thursday 03 April 2008 15:09:30 you wrote:
>  > > If set individually, the multiple breakpoint locations can be used with
>  > > deleted, ignore, condition and commands.  
>  > 
>  > To set individual breakpoint on constructor instances, for example,
>  > you need to set breakpoint at address.
>  > 
>  > > Why would this not true when the 
>  > > location is part of a multiple breakpoint?  Is it just due to the
>  > > implementation or a fundamental limitation?
>  > 
>  > That's the design of multiple-location breakpoints. You specify the line
>  > or function on which such a breakpoint should be set. GDB that arranges
>  > for the list of locations to automatically include all relevant addresses,
>  > including when shared libraries are loaded and unloaded. Note that while
>  > there's mechanism to enable and disable individual locations, it's a bit
>  > heuristic, so the enable/disable state might not be carried over when
>  > new shared libraries are loaded.
>  > 
>  > Allowing the user to manipulate individual locations will interfere with
>  > this automatic updating of location list. 
> 
> I'm not familar with the need to load and unload shared libraries, Gdb just
> loads them automatically for me.

And while it loads them automatically, it also updates breakpoints. In particular
new locations may be added to a breakpoint. Was this not clear from what I wrote
above?

> 
>  >                                           Furthermore, what is the use case?
>  > For constructors, one is not likely to ever want to do anything with
>  > individual locations. For inlined functions, I don't know why you would
>  > specifically treat one inlined instance, but if you wish, you can always
>  > create a more specific breakpoint, like on address, and do anything.
>  > 
>  > Of course, we can provide a command that creates individual breakpoints on
>  > each address matching a specification, and does not do any auto-update of
>  > those breakpoints. If you think such a behaviour will be useful, can you
>  > explain why, and then work on implementing it?
> 
> I can imagine it might be useful to control the breakpoint locations
> individually but, in practice I've never needed multiple breakpoints yet.
> However, if it's not useful then it's probably unlikely that anyone would
> try to do it in a frontend as you suggested earlier:
> 
> 
>      Yes, but those are not a breakpoints, do it will do a disservice to the
>      existing frontends. In particular, might find it very interesting
>      experience to edit condition of one breakpoint, and having conditions on
>      other breakpoints change. Likewise, changing any properly of location will
>      not work.

So, you suggest that frontend should display a number of fields for breakpoint
locations in the hope that the user will never touch those fields? This will
just clutter the UI. 
 
- Volodya