MI3 and async notifications

Joel Brobecker brobecker@adacore.com
Mon Jun 17 12:14:00 GMT 2019

> > It seems like a good idea to me.  I wonder if it makes sense to go even
> > further and say there will only be async notifications for things like
> > this.
> Yes, I thought the same initially. But then what about other existing MI
> consumers? 
> >From what I understood from Jonah's comments earlier, this would break (at least)
> CDT. So CDT would either have to stick with MI2 (not great in a long
> term) or refactor their code (not sure CDT guys would be happy to do
> so, especially as - I presume - CDT needs to support wide range of GDB
> versions already in the wild, a problem I do not have). 
> While I personally agree with you and will be happy to go that far,
> it'd break existing consumers - something that should IMO be carefully
> discussed and planned. 
> Adding a new option as I proposed as an alternative will be backward
> compatible, indeed at the cost of more convoluted code in GDB itself. 
> Is anyone from Emacs community around? Or any other MI consumers? 

My 2 cents:

In my opinion, while I think upward compatibility is very important,
it is also important to avoid having too many configurability options.
Otherwise, we end up with a large number of options and the testing
matrix, if we want to verify that they work well together, quickly

In this case, because we have MI versions, and because the notification
shouldn't be different from the data of the "^done" message, I think
the incompatibility would be acceptable -- assuming existing parsers
don't come back to say that it actually is a large effort for them
to adapt.


More information about the Gdb mailing list