From: Yao Qi <yao@codesourcery.com>
To: andre <apoenitz@t-online.de>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
Date: Fri, 07 Feb 2014 09:14:00 -0000 [thread overview]
Message-ID: <52F4A366.6060704@codesourcery.com> (raw)
In-Reply-To: <20140206203936.GA7055@klara.mpi.htwm.de>
On 02/07/2014 04:39 AM, andre wrote:
> I understand the patch, but I do not understand the motivation behind
> the design decision to not send notifications when the change is
> triggered by an MI command.
>
The rationale is mentioned here
https://sourceware.org/ml/gdb-patches/2012-07/msg00487.html
In short, we want MI frontend is aware of GDB's state changes, such as
breakpoint changes. If requested changes are from MI, MI frontend
should be aware of them, so no notifications are sent.
> Let's assume a frontend wants to have a functional gdb "console" embedded,
> and the frontend in general runs in MI mode.
>
> A trivial implementation would pass user input unfiltered to gdb. A user
> can choose to type 'disable 1', or, with the same effect on gdb internal
> state, '-break-disable 1'. In the first case, the frontend currently will
> get a notification, in the second case it will not.
>
> To get reliable information about the actual gdb internal state in this
> setup there are essentially three choices for a frontend developer:
>
> - prevent the user from entering MI commands in the console
> (and try to catch all possible workarounds to sneak in MI
> commands nevertheless),
>
> - pre-parse user input before sending it to gdb, try to recognize
> MI commands that are known to not produce notifications and
> interpret a ^done as "all fine according to whatever you currently
> think 'fine' means",
>
> - ignore =breakpoint-modified notification in general and try to get
> full information using other means.
>
> None of these options is desirable. None would be needed if gdb in
> MI mode would simply announce all (non-internal) breakpoint modifications
> with =breakpoint-modified notifications.
#1 is fine to me. It shouldn't be hard to do that. On the other hand,
I don't understand users have to input MI commands in console, which
is provided to accept CLI commands.
>
> I would pretty much prefer notifications on all breakpoint changes in
> MI mode, no matter whether they are initiated by an MI or a non-MI command.
That would be too noisy in some cases.
--
Yao (é½å°§)
next prev parent reply other threads:[~2014-02-07 9:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 7:48 Yao Qi
2014-02-06 12:38 ` Yao Qi
2014-02-06 20:39 ` andre
2014-02-07 9:14 ` Yao Qi [this message]
2014-02-07 16:12 ` andre
2014-02-08 3:18 ` Joel Brobecker
2014-02-08 3:39 ` Yao Qi
2014-02-08 13:15 ` Joel Brobecker
2014-02-08 14:11 ` andre
2014-02-07 14:04 ` Pedro Alves
2014-02-08 1:49 ` Yao Qi
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=52F4A366.6060704@codesourcery.com \
--to=yao@codesourcery.com \
--cc=apoenitz@t-online.de \
--cc=gdb-patches@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