Re: Simplify MI breakpoint setting

[Vladimir Prus <vladimir@codesourcery.com>]

On Tuesday 08 September 2009 Matt Rice wrote:

> On Mon, Aug 31, 2009 at 10:16 PM, Vladimir
> Prus<vladimir@codesourcery.com> wrote:
> > On Tuesday 01 September 2009 Tom Tromey wrote:
> >
> >> >>>>> "Volodya" == Vladimir Prus <vladimir@codesourcery.com> writes:
> >>
> >> Volodya> And, progressing recursively, what is the point of not exposing
> >> Volodya> all the parameters of break_command_really?
> >>
> >> I don't actually know.  But if I had to guess, I would say it is because
> >> providing wrappers ensures you can't pass in some forms of nonsense.
> >>
> >> If you really want to do it, and nobody objects, then I guess I don't
> >> care all that much.  This whole API seems a bit nuts, any time you have
> >> 13 arguments you should just assume you've done something wrong already.
> >>
> >> I do care about not exporting a function named "break_command_really"
> >> though.
> >
> > Ok. I imagine that break_command_really can be renamed to set_breakpoint :-)
> >
> 
> here are my thoughts,
> 
> I don't like how break_command_really looks for the symbol first, then
> if it fails to find one and
> pending breakpoints are enabled it will set a pending breakpoint, I
> think it might sometimes make sense
> to set a pending breakpoint even though there may be a match.

I am missing something. Pending breakpoint, by definition, is a breakpoint
that has zero locations. And breakpoint can have zero locations if and only
if we have failed to find any location that corresponds to the string
that user has specified. Therefore, pending breakpoint for a found symbol
or line seems just impossible.

> 
> though I do think that the break_command_really behaviour is good for
> the  'break command'
> if we were to introduce a 'pbreak', or pending breakpoint command, I
> could imagine pbreak_command_really or something calling something
> named set_breakpoint, but that is not just renaming
> break_command_really.
> 
> similarly, there is currently no way to do 'set multiple-symbols
> pending' or all+pending,
> and making 'set multiple-symbols ask' respond like this:
> 
> [0] cancel
> [1] all
> [2] pending
> 
> (note that you could select  (1 2) get all, and a pending
> or 2 and just set a pending breakpoint.
> (now you'll have to ignore all the rest of the stuff you can think of
> required to make this behaviour anything but annoying)

It is true that interaction of the 'set multiple breakpoints for
each overloaded function' functionality with the multiple-location
functionality is not much designed.

- Volodya