Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: andre <apoenitz@t-online.de>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
Date: Thu, 06 Feb 2014 20:39:00 -0000	[thread overview]
Message-ID: <20140206203936.GA7055@klara.mpi.htwm.de> (raw)
In-Reply-To: <52F381B0.4010602@codesourcery.com>

On Thu, Feb 06, 2014 at 08:36:00PM +0800, Yao Qi wrote:
> On 01/24/2014 03:46 PM, Yao Qi wrote:
> > As design, =breakpoint-modified isn't emitted when breakpoints are modified
> > by MI commands.  This patch is to add tests for this.
> > 
> > gdb/testsuite:
> > 
> > 2014-01-24  Yao Qi  <yao@codesourcery.com>
> > 
> > 	* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test
> > 	that no =breakpoint-modified is emitted when breakpoints are
> > 	modified through MI commands.
> 
> Ping.  https://sourceware.org/ml/gdb-patches/2014-01/msg00915.html

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.

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.

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.

Andre'


  reply	other threads:[~2014-02-06 20:39 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 [this message]
2014-02-07  9:14     ` Yao Qi
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=20140206203936.GA7055@klara.mpi.htwm.de \
    --to=apoenitz@t-online.de \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /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