bug#62697: gdb-mi.el: Change target-async to mi-async

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 6 Apr 2023 18:26:48 -0700
> Cc: 62697@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 4/6/2023 6:32 AM, Eli Zaretskii wrote:
> > We could either (1) ask GDB about its version, or (2) filter out the
> > annoying message so it isn't shown to the users; we'd then have to
> > revisit this if/when GDB actually drops the command, if it ever does.
> > 
> > Alternative (1) is AFAIR problematic because the initialization of a
> > GDB session under Emacs is entirely asynchronous, so sending a command
> > and waiting for its response before sending the rest is not easy.  So
> > I tend to the second alternative.
> 
> I don't know much about gdb-mi.el's internals, but taking a quick look 
> at the code, 'gdb-input' takes a callback, so something like the 
> following pseudocode would probably do the trick?

The problem is not with the callback, the problem is with _when_ the
callback is called.  gdb-mi doesn't wait for each gdb-input call to
complete and its callback called before calling the next gdb-input.
In practice, we send a dozen gdb-input commands before the response
for the first one is received and its callback called.  You can
clearly see that if you enable gdb-enable-debug and look at the log it
collects.

So sending a command via gdb-input, then conditioning another command
on it is not trivial, since the callback could be called much later.

>    (gdb-input "-gdb-version"
>     (lambda ()
>       (if (gdb-should-use-mi-async)  ; Check the version output.
>           (gdb-input "-gdb-set mi-async on" #'ignore)
>         (gdb-input "-gdb-set target-async on" #'ignore))
>       (gdb-input "-list-target-features" #'gdb-check-target-async)))
> 
> The existing 'gdb-check-target-async' already chains GDB-MI commands 
> like this, so I imagine the above will Just Work.

It "will work", but what if the other commands sent via the other
gdb-input calls during initialization depend, or change the GDB
behavior depending, on whether mi-async was or wasn't already sent?
Or are you saying that mi-async can be sent anywhere during the
initialization sequence, including after it finishes?  The GDB manual
says:

  The frontend may specify a preference for asynchronous execution
  using the '-gdb-set mi-async 1' command, which should be emitted
  before either running the executable or attaching to the target.

If GDB is invoked with, e.g., "gdb -p PID", then we need to send this
command up front, before GDB attaches.

And there could be other issues with that proposal.  Which is why I
said that alternative was "problematic".  Filtering out the annoying
message is much safer, IMO.