This is the mail archive of the
mailing list for the GDB project.
Re: bug in mi when setting breakpoint
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:
> > ~" cancel\n all\n"
> > ~" classname::function_name(int) at fooprog.cc:65\n"
> > ~" 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
> change broke this behaviour? I suspect it was the change to readline made
> 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
> command. I don't think that they fit well with the MI paradigm: MI
> 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.