This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands


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'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]