MI3 and async notifications

Jonah Graham jonah@kichwacoders.com
Mon Jun 10 23:23:00 GMT 2019


On Mon, 10 Jun 2019 at 17:19, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

> Therefore I'd like to propose a change for MI3 to always send
> notifications.
> If such a change would make things complicated for other frontends
> (Eclipse CDT / Emacs come to mind), I propose new
>
> -gdb-set mi-always-notify 1
> -gdb-set mi-always-notify 0
>

Thank you for considering the other front end consumers of MI. I am one of
the current maintainers of CDT so I will share my 2cents.

Eclipse CDT would certainly require such a flag, but only if MI3 was a
replacement for MI2. If CDT can continue to use gdb in mi2 mode (CDT
launches gdb with --interpreter mi2 [1]) then I don't think you need to
carry on the extra logic in MI3. I haven't followed the discussions on MI3
closely.

I assume from the proposal that the -break-insert still gets the done
message with the breakpoint number in it? And does the async message come
back after the the ^done? If it does not come after the done CDT will have
to hold processing the async message until after it finds out if the
=breakpoint-created was for the MI or CLI inserted breakpoint (consider the
race condition that a user / script inserts a breakpoint from the CLI at
the same time as from the MI).

I hope that helps from CDT perspective.

Jonah

[1]
https://github.com/eclipse-cdt/cdt/blob/7741bd98f7b08a281c4b7f60e60c5839f315f760/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBBackend.java#L188



More information about the Gdb mailing list