This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH, gdb6.8] -break-list doesn't list multiple breakpoints
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
> > 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.