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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gustaf Waldemarson <gustaf.waldemarson <at> gmail.com>
Cc: 62697 <at> debbugs.gnu.org
Subject: bug#62697: gdb-mi.el: Change target-async to mi-async
Date: Thu, 06 Apr 2023 16:32:46 +0300

> From: Gustaf Waldemarson <gustaf.waldemarson <at> gmail.com>
> Date: Thu, 6 Apr 2023 14:48:20 +0200
> 
> This may be a bit too early, given how prevalent it is to be using older
> versions of GDB but I figured I should send this patch anyways to get it out of
> my mind:
> 
> For GDB version >= 11, starting up a debugging session with 'gdb-mi.el' always
> ends with this message:
> 
> > (gdb) Warning: 'set target-async', an alias for the command 'set mi-async', is
> > deprecated.  Use 'set mi-async'.
> 
> This is a bit of an eyesore and also breaks the initial prompt (although that is
> easily fixed by pressing enter, etc, but that may still be confusing for new
> users).
> 
> It may be reasonable to either query the GDB version (not sure how though,
> unfortunately) and then use the old command (`set target-async`) or execute the
> non-deprecated command instead (`set mi-async`), and then possibly trying the
> old on if the new one did not work.
> 
> Apparently, `set mi-async` is a GDB 7.8 feature (Released Jul 2014), so this
> change may cause incompatibilities with earlier GDB versions. That said, I
> suspect that it will only cause a warning message to appear for using an
> unsupported command, but unfortunately I don't have an old enough version of GDB
> handy to try that out.
> 
> Any strong opinions either way? The attached patch only replaces the old command
> with the new one, but I'm open for suggestions.

We cannot simply replace the command, as GDB 7.8 is not old enough to
assume it isn't used anymore.

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.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.