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 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 (éå)


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