Re: bug in mi when setting breakpoint

[Vladimir Prus <ghost@cs.msu.su>]

Nick Roberts wrote:

>  > In that case, the breakpoint setting code
>  > asks the user to choose the overloaded function it wants to break in.
>  > To do so, the breakpoint setting code displays something like:
>  > 
>  > ~"[0] cancel\n[1] all\n"
>  > ~"[2] classname::function_name(int) at fooprog.cc:65\n"
>  > ~"[3] classname::function_name() at fooprog.cc:59\n"
>  > ~"> "
>  > 
>  > The last line of this "question" is the default prompt indicating the
>  > end of the question.
>  > 
>  > In gdb 6.7.1, that prompt is missing *only* when using the MI
>  > interpreter. It is present in the CLI interpreter. And this is a
>  > regression from 6.6 where the prompt was present with both
>  > interpreters.
> 
> Your patch appears to introduce new behaviour.  The question to ask is
> what
> change broke this behaviour?  I suspect it was the change to readline made
> at
> the start to this year.  GDB seems to go into gdb_readline_wrapper from
> decode_line_2 and stay there.
> 
>  > The prompt is really important for graphical front-end tools willing
>  > to parse that "question" so that they can display display it
>  > back to the user in a nice windowed manner.
>  > As the question does not really respect the GDB/MI output format where
>  > the output should be ended by a "(gdb)" string, the prompt is the only
>  > way th front end can detect the end of the "question".
>  > 
>  > So I tried to produce the attached patch to pinpoint the problem and
>  > hopefully propose a fix.
> 
> Unfortunately CLI also uses sub-prompts for several other commands:
> queries e.g pending breakpoints, exiting after exevution has started; the
> "commands"
> command.  I don't think that they fit well with the MI paradigm: MI
> expects
> MI output.  With queries, GDB takes affirmative action, e.g., creates
> pending breakpoints regardless of the value of "show breakpoint pending"

I don't think that's true. Week old CVS HEAD won't ever create pending
breakpoint when using MI. Today's CVS HEAD will create pending breakpoint
if you use the -f option to -break-insert. Without that option, pending
breakpoint won't ever be created.

> and exits regardless of the value of "show confirm".
> 
> Perhaps, for now, GDB could do something similar, i.e., set all the
> breakpoints in the breakpoint menu.

In general, I think that any command that requires any interactivity
should explicitly document how it would handle that.

- Volodya