From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 62697@debbugs.gnu.org, gustaf.waldemarson@gmail.com
Subject: bug#62697: gdb-mi.el: Change target-async to mi-async
Date: Fri, 7 Apr 2023 00:25:03 -0700 [thread overview]
Message-ID: <b11ac19e-ba8d-1f3e-619d-916d0f4ea92e@gmail.com> (raw)
In-Reply-To: <83h6tsp5s1.fsf@gnu.org>
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.
next prev parent reply other threads:[~2023-04-07 7:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 12:48 bug#62697: gdb-mi.el: Change target-async to mi-async Gustaf Waldemarson
2023-04-06 13:32 ` Eli Zaretskii
2023-04-07 1:26 ` Jim Porter
2023-04-07 6:26 ` Eli Zaretskii
2023-04-07 7:25 ` Jim Porter [this message]
2023-04-07 10:29 ` Eli Zaretskii
2023-04-07 10:36 ` Gustaf Waldemarson
2023-04-07 10:53 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b11ac19e-ba8d-1f3e-619d-916d0f4ea92e@gmail.com \
--to=jporterbugs@gmail.com \
--cc=62697@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=gustaf.waldemarson@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).