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

[Jim Porter <jporterbugs@gmail.com>]

On 4/6/2023 11:26 PM, Eli Zaretskii wrote:
> 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.

Maybe I'm just misunderstanding something, but it looks like "-gdb-set 
target-async 1" is already sent from a callback: specifically, the one 
for "-gdb-set non-stop 1". Is this code already violating GDB's rules? 
Would adding another layer of callback make it any worse? Maybe so, but 
if we're worried about the latter, then couldn't we do something like:

------------------------------

(defun gdb-init-1 ()
   ;; ...

   ;; Add this call:
   (gdb-input "-gdb-version" #'gdb-version-handler)

   ;; ...
   ;; This is existing code:
   (when gdb-non-stop
     (gdb-input "-gdb-set non-stop 1" 'gdb-non-stop-handler))
   ;; ...
   )

(defun gdb-version-handler ()
   (setq gdb-version (some-logic-here)))

;; This is also existing code:
(defun gdb-non-stop-handler ()
   ;; By here, 'gdb-version-handler' should have been called, right?
   ;; I'm assuming handlers are called in the same order as the input was
   ;; sent to gdb.  If so, just check 'gdb-version' and do the right
   ;; thing.
   )

------------------------------

Assuming handlers are called in the same order as their inputs are sent, 
this should work, and then everything will happen in the same order as 
gdb-mi.el currently does.

My main worry with just suppressing the warning is that presumably at 
some point in the future, GDB will remove the old form entirely, and 
then gdb-mi.el breaks. If we could get this code to use the new form 
when available, then there's no need to worry about having to publish a 
hotfix for gdb-mi.el on short notice.