|
From: | Jim Porter |
Subject: | bug#62697: gdb-mi.el: Change target-async to mi-async |
Date: | Fri, 7 Apr 2023 00:25:03 -0700 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |