This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
- From: andre <apoenitz at t-online dot de>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 6 Feb 2014 21:39:36 +0100
- Subject: Re: [PATCH] Test no =breakpoint-modified is emitted for modifications from MI commands
- Authentication-results: sourceware.org; auth=none
- References: <1390549587-23625-1-git-send-email-yao at codesourcery dot com> <52F381B0 dot 4010602 at codesourcery dot 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'