Re: bug in mi when setting breakpoint

Nick Roberts
2007-12-16T20:42:04Z

> 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" 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.