Re: bug in mi when setting breakpoint

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > 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.
 > 
 > I am not aware of the exact changeset that changed the behaviour. Could you
 > point me to it please ? I am only aware of what is in gdb 6.7.1 now, sorry.
 
I think it's this one:

2007-01-03  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.in (top.o): Update.
	* top.c (gdb_readline_wrapper_done, gdb_readline_wrapper_result)
	(saved_after_char_processing_hook, gdb_readline_wrapper_line)
	(struct gdb_readline_wrapper_cleanup, gdb_readline_wrapper_cleanup):
	New.
	(gdb_readline_wrapper): Rewrite to use asynchronous readline.

I see behaviour changed around that time.

 > But yeah, it actually boils down to the decode_line_2() that calls
 > command_line_input() to get input from the user (and display a prompt at
 > the same time).
 > 
 > That code patch It eventually ends up in display_gdb_prompt() which job is
 > to (surprise!) display our now famous prompt.
 > 
 > One of the first thing that display_gdb_prompt() does is to check if the
 > current interpreter has disabled prompts or not, by calling
 > current_interp_display_prompt_p(). This last function calls returns 0,
 > meaning that the current interpreter (in my case MI) disallows prompts so
 > the prompt is simply not displayed.
 > 
 > So in short, MI disallows prompts. It does this by setting the member
 > prompt_proc_p of the struct interp_procs to a function that always returns
 > 0. This is done in _initialize_mi_interp() (in gdb/mi/mi-interp.c).

Why does MI disallow prompts?  Presumably it's for good reason and perhaps
you're trying to subvert that.  The function gdb_readline_wrapper used to
be just that: a wrapper for readline.  It didn't used to do things like
call display_gdb_prompt.  Perhaps its name should be changed.

 > [...]
 > 
 > > 
 > > 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".
 > 
 > I am not sure to understand why are saying this here :-)
 > But for what it is worth, the CLI interpreter allows prompt, yes. I am not
 > sure to understand why it is unfortunatel

I'm trying to say that sub-prompts are really for the command line.

 > > 
 > > Perhaps, for now, GDB could do something similar, i.e., set all the breakpoints
 > > in the breakpoint menu.
 > 
 > Hmmh, no. I think it is important to stay consistent with the format of the
 > "question" asked to the user in the pre 6.7.1 and make that question be
 > followed by a prompt. Otherwise this would break existing front ends.

It's probably important not to break existing use, if possible, but you
appear to be parsing CLI output that hasn't really been designed for use
with front ends.  So I don't think it's a question of being consistent.

-- 
Nick                                           http://www.inet.net.nz/~nickrob