This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI3 and async notifications
On Mon, Jun 17, 2019 at 11:53:14AM +0100, Jan Vrany wrote:
> On Sat, 2019-06-15 at 08:34 -0600, Tom Tromey wrote:
> > > > > > > "Jan" == Jan Vrany <jan.vrany@fit.cvut.cz> writes:
> >
> > Jan> as an user og GDB/MI (and frontent developer), I'd like to Jan>
> > open a discussion about one aspect of MI that I'd like to change Jan> in
> > MI3 before it is released into the wild. ... Jan> Emitting
> > notifications unconditionally would simplify things a lot Jan> - again
> > at least in my case.
> >
> > 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?
Some "other (partial) MI consumer" here. And thank you for considering that
possibility.
1. I also need to support a range of GDB versions (current lower limit is
7.4.1, but I guess I could bump that a bit if really needed)
2. Any kind of additional notification that does not change change
sequencing or contents of messages of older versions sounds ok to me.
3. Output of gdb --version/show version, -list-features etc was in the past
insufficient for me for feature discovery, so I typically use
trial-and-error-and-fallback on some test input, or, in the areas where it
is available, use the Python interface instead of MI. Insofar, I do not need
backward compatibility in the sense that later versions need to continue to
provide a specific feature, it's typically ok if a feature/command is either
there or not. I believe completely removing features/command would be easier
for me to handle than certain cases where there features only slightly
change behaviour or need special setup to establish a "compatibility mode"
or such.
Andre'