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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 7 Apr 2023 00:25:03 -0700
> Cc: 62697@debbugs.gnu.org, gustaf.waldemarson@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 4/6/2023 11:26 PM, Eli Zaretskii wrote:
> > 
> >    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? 

I don't know.

> Would adding another layer of callback make it any worse?

I don't know.

> Maybe so, but if we're worried about the latter, then couldn't we do
> something like:

I don't know!  It will take someone who knows a lot more than I do
about both GDB/MI and gdb-mi.el to tell, and the changes need to be
tested with many different versions of GDB.  Feel free to do that and
see if those changes are benign, and then we can install them.
Failing that, given that we don't have an active enough maintainer of
gdb-mi.el on board, I feel that suppressing the annoying message is a
much more easy way out.

> Assuming handlers are called in the same order as their inputs are sent, 

They are called in the order in which responses for inputs are
received, not in the order these inputs are sent.  I don't think these
are the same orders, at least they aren't guaranteed to be.  You can
see this by yourself if you enable the gdb-mi debug mode (each
response is tagged with the number of the corresponding input command,
and those numbers are given to commands by gdb-mi.el in the order it
sends the commands).

> 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.

I'm not even sure this will be removed at all.  It certainly won't be
removed soon, as they just recently started issuing a warning.  For
example, the annotations feature of GDB, use by "M-x gud-gdb", is
still being supported, although it became deprecated as soon as GDB/MI
was added to GDB.

> 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.

I agree.  But if adding that means dealing with tricky
timing-dependent and version-dependent bugs, I prefer to use a less
radical solution, even if it's less clean and less future-proof.

Btw, as an easy alternative, we could add a defcustom whose value
would be the minimum supported value of GDB.  Then users could set it
to, say, 7.8.0, to force gdb-mi.el to use mi-async, and by that avoid
the annoyance.  This could even go into Emacs 29.