bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64186: Patch: Suppress deprecated '-gdb-set target-async' warning me


From: Eli Zaretskii
Subject: bug#64186: Patch: Suppress deprecated '-gdb-set target-async' warning message in gdb-mi.el
Date: Tue, 20 Jun 2023 14:55:56 +0300

> Cc: 64186@debbugs.gnu.org
> From: Wang Diancheng <dianchengwang@gmail.com>
> Date: Tue, 20 Jun 2023 17:25:06 +0800
> 
> Po Lu <luangruo@yahoo.com> 于2023年6月20日周二 15:24写道:
> >
> > What about versions of GDB earlier than 7.7?  We should detect them, and
> > use `set mi-async' there.
> >
> Like other places of gdb-mi.el,  function gdb-set-mi-async-handler()
> will use 'set target-async' if GDB (versions earlier than 7.7) reports
> "No symbol".

Isn't that too late, though?  The GDB manual says:

  On some targets, GDB is capable of processing MI commands even while the
  target is running.  This is called "asynchronous command execution"
  (*note Background Execution::).  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.

However, the gdb-input call sends the request without waiting for the
response, so the handler of the response will be invoked much later,
after GDB already processed quite a few commands sent to it by Emacs
in the meantime.  Thus, by the time gdb-set-mi-async-handler is
called, and we see the "No symbol" thingy and send the target-async
command instead, it could be too late, because the executable was
already run.

There's actually more here than meets the eye; see bug#63084.

Given all that mess, I wonder if "M-x gdb" in its current shape indeed
supports the asynchronous execution.  If it doesn't, we may be better
off not sending that command at all for now, until bug#63084 is fixed.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]