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: Fri, 7 Feb 2014 17:12:21 +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> <20140206203936 dot GA7055 at klara dot mpi dot htwm dot de> <52F4A366 dot 6060704 at codesourcery dot com>
On Fri, Feb 07, 2014 at 05:12:06PM +0800, Yao Qi wrote:
> 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
Sure, but I don't understand it. You argue that it is necessary for a
frontend to keep track of changes triggered by manual user interaction.
That's fine. But it is unclear why this reasoning should only be
applied to non-MI commands, and not for MI commands that a user enters
manually (and that gdb happily accepts).
> 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.
> > 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.
But not for me. I don't want to needlessly restrict what my users are
allowed to type, or not. It might even e.g. be useful to copy/paste/modify
previously sent MI commands and send them manually via the console. In your
approach this would not be possible, or at least require the user to
re-write the full command in non-MI syntax.
> 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.
The point is not that they should _have to_ use MI syntax, but that they
_could_ if they wish.
> > 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.
It's easier for a frontend to filter out messages (especially if they
are expected) than to act on messages that are not send. And it's not
that we are talking about millions of notifications here that might
the communication line.`
Andre'