From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#62697: gdb-mi.el: Change target-async to mi-async Date: Fri, 7 Apr 2023 00:25:03 -0700 Message-ID: References: <835ya9qgox.fsf@gnu.org> <79ec3700-02ab-7574-1411-dfef0ec5eb7f@gmail.com> <83h6tsp5s1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32833"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62697@debbugs.gnu.org, gustaf.waldemarson@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 07 09:26:29 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pkgUP-0008QA-9O for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 07 Apr 2023 09:26:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pkgU7-00018M-1j; Fri, 07 Apr 2023 03:26:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pkgTz-00016U-Ab for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 03:26:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pkgTy-0002YW-I3 for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 03:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pkgTx-0008Jv-Ry for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 03:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Apr 2023 07:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62697 X-GNU-PR-Package: emacs Original-Received: via spool by 62697-submit@debbugs.gnu.org id=B62697.168085231931930 (code B ref 62697); Fri, 07 Apr 2023 07:26:01 +0000 Original-Received: (at 62697) by debbugs.gnu.org; 7 Apr 2023 07:25:19 +0000 Original-Received: from localhost ([127.0.0.1]:55626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkgTC-0008Is-IH for submit@debbugs.gnu.org; Fri, 07 Apr 2023 03:25:18 -0400 Original-Received: from mail-pj1-f53.google.com ([209.85.216.53]:41767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkgT7-0008IZ-R7 for 62697@debbugs.gnu.org; Fri, 07 Apr 2023 03:25:13 -0400 Original-Received: by mail-pj1-f53.google.com with SMTP id fy10-20020a17090b020a00b0023b4bcf0727so42720808pjb.0 for <62697@debbugs.gnu.org>; Fri, 07 Apr 2023 00:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680852304; x=1683444304; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=CbbYsPQuWb09M9Y3pk94m/nwaqdtvMMQaDoPkM/tWFs=; b=MeV60wajuUnVK26tXsyD6FdG5JBynMZZd34NPIBOxeJZW+lWjEjXSJei1W7UUoh3T3 sOJiekQU1Ws1sG7QErZZTjSJHfp6gj3XHbr46m8t6rX3YsMnzKRpqmcx8eBnyB5juMu0 4f7dcZiMC0gD4ODBUH7SdOWIxk1QeZl9Ml1plX2/ahhuX3LSs7yz/nuSoLMWfHzALcsO psRsmZoSeB6i631AszaiCRB5rJCuux9WQsd4KhkeY3mp/KLzccE3JRv8RnWp4coVzsob EkRlBj0GaCO+/P1Ty2mSneRV/V6p0dRIJ2HoyGOhGbFzaTi7dncpExQvymKqmd8TM2SN vDvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680852304; x=1683444304; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CbbYsPQuWb09M9Y3pk94m/nwaqdtvMMQaDoPkM/tWFs=; b=DeEHcGBk+b/AP4yc2Pxr1rSFtNPjhNnMW0agUT62n6a1ObPQTqAr66g2QBcQgKO5+X WFrhJs0alLRWIXITZwpe5q7QppfPl8ziUMNPuINurXwacKIz6coVtXsWEfPr9xutL4XQ XmAXi8SmQ2JNBQVIZTDiriMkuz9j+iXVCNjDbFOPug53F8GQh/yP8trVgrKRKhX4XOUM heM48rRepTehvGUHsqW2/cwR14lqnz//8YVHrmP/hWe2rlU7LBbNWBMZ16rmuVdvP6Ki 96C88r4oXiOCSw2Tn0M3yI8ZrugvPSFoMt5Rrjo8XxpJzPzOJh7SIKg0EUDu5mgLraRh YjyA== X-Gm-Message-State: AAQBX9dpWnxuVZk/O8hPhPC1jO412QzrNUFXMG65P7urb8nT5m4tYhr7 aZ5fYu9gNdet+gAhRYfmRrQ= X-Google-Smtp-Source: AKy350YKpXfHiFOz6cwa5+r8CLrB0Q+TRNqPMPf9dwR6HLzgv4nmggQWgtXpbWxlx+K1+LB2wdKTVg== X-Received: by 2002:a17:90b:3a8f:b0:246:57f6:44b5 with SMTP id om15-20020a17090b3a8f00b0024657f644b5mr805870pjb.12.1680852303651; Fri, 07 Apr 2023 00:25:03 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id y13-20020a17090a154d00b002376d85844dsm495232pja.51.2023.04.07.00.25.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Apr 2023 00:25:03 -0700 (PDT) Content-Language: en-US In-Reply-To: <83h6tsp5s1.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259367 Archived-At: 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.