From: Nick Roberts <nickrob@snap.net.nz>
To: dodji@seketeli.org
Cc: gdb@sourceware.org
Subject: Re: bug in mi when setting breakpoint
Date: Sun, 16 Dec 2007 20:42:00 -0000 [thread overview]
Message-ID: <18277.36237.521792.245470@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20071216125625.GE4783@coin>
> 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.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-12-16 20:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-16 12:56 Dodji Seketeli
2007-12-16 20:42 ` Nick Roberts [this message]
2007-12-16 21:21 ` Vladimir Prus
2007-12-16 22:00 ` Nick Roberts
2007-12-17 9:30 ` Dodji Seketeli
2007-12-17 11:04 ` Nick Roberts
2007-12-17 11:43 ` Dodji Seketeli
2008-01-15 3:37 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18277.36237.521792.245470@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=dodji@seketeli.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox