From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62697: gdb-mi.el: Change target-async to mi-async Date: Fri, 07 Apr 2023 13:53:59 +0300 Message-ID: <834jpsotdk.fsf@gnu.org> References: <835ya9qgox.fsf@gnu.org> <79ec3700-02ab-7574-1411-dfef0ec5eb7f@gmail.com> <83h6tsp5s1.fsf@gnu.org> <83bkk0ouhx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25705"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, 62697@debbugs.gnu.org To: Gustaf Waldemarson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 07 12:54:24 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 1pkjjc-0006Wu-Fu for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 07 Apr 2023 12:54:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pkjjI-0001AM-By; Fri, 07 Apr 2023 06:54:04 -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 1pkjjH-0001A2-6Y for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:54:03 -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 1pkjjG-0008U0-Ur for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pkjjG-0000Ls-Rw for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Apr 2023 10:54:02 +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.16808648151307 (code B ref 62697); Fri, 07 Apr 2023 10:54:02 +0000 Original-Received: (at 62697) by debbugs.gnu.org; 7 Apr 2023 10:53:35 +0000 Original-Received: from localhost ([127.0.0.1]:55771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkjio-0000L0-W3 for submit@debbugs.gnu.org; Fri, 07 Apr 2023 06:53:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkjin-0000Ko-Nn for 62697@debbugs.gnu.org; Fri, 07 Apr 2023 06:53:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pkjii-0008Ly-6a; Fri, 07 Apr 2023 06:53:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TZsbHuySFWYrVwyKS8fiyqhBB6tCH4ccqYk7PkLwdVk=; b=iBc9YE969wfk jmJTdwTMcxGNQAqnZRrRU3v+X+eL2+UP/Z3eHYdB41DG/XqvEbrQ4cPDgBhPm6MNaoomRbDevuRUo TuqUyd+ukuIl0Az44515cWfju9WdjbohQ0FhBlxZAkqnSCuX13UMhh5LGlmlZLJCIY/0QzrPejcPc beAp8YwON0g/SHhy11A0FRBNFhoujwL7M24ANLYH7QXrFf8p7apwXLjNm32RptI1cSYHk3TGP/ICx fjevcxUhf0RDAkYqhVcc/AYZSEFvZnAN0oWMbmlWjUBIhksUQ6lc2RJRxXuvIi/MrXZKPzTdlGTtD LcqVqrUZU3/ueVsyOIypMQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pkjih-0004ib-Ds; Fri, 07 Apr 2023 06:53:27 -0400 In-Reply-To: (message from Gustaf Waldemarson on Fri, 7 Apr 2023 12:36:31 +0200) 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:259382 Archived-At: > From: Gustaf Waldemarson > Date: Fri, 7 Apr 2023 12:36:31 +0200 > Cc: Jim Porter , 62697@debbugs.gnu.org > > Filtering the message is probably easy, but as Jim pointed out, it will probably > have unintended consequences later on. Leave that problem to me (or to the maintainer that will come after me). The problem you raised was with the annoying message; let's solve that first and foremost. > Besides, extracting the version could > enable a lot of different things down the line. It could, but it is "tricky", as you have discovered (and I discovered before you). > I had actually started on a "check-gdb-version-string", but was never able to > get it to work. In fact, revisiting that code now makes we wonder if any of these > "handlers" are actually working as intended. They do work. It's just that the way this is implemented is "tricky", as I said from the get-go. > From what I can see, the handlers scan the current buffer (which one is that anyways?) > to determine whether to do some operations. However, adding some prints to > these handlers reveal that they seem to always be empty: > > (defun gdb-non-stop-handler () > (goto-char (point-min)) > (print (buffer-substring-no-properties (point-min) (point-max))) > (if (re-search-forward "No symbol" nil t) > (progn > (message > "This version of GDB doesn't support non-stop mode. Turning it off.") > (setq gdb-non-stop nil) > (setq gdb-supports-non-stop nil)) > (setq gdb-supports-non-stop t) > (gdb-input "-gdb-set mi-async on" 'ignore) > (gdb-input "-list-target-features" 'gdb-check-mi-async))) The "No symbol" text means that we have invoked a command that is not supported by the GDB you have installed. Unless you test this with a very old version of GDB, you will never see that text. The way these commands work is like this: . gdb-input sends a command which has a serial number (the numbers are allocated by gdb-mi.el in increasing order, starting from 1) . gdb-input also registers a callback for the response . when the response is received, it is recognized by the serial number (GDB responds with the same serial number as the command to which it responded), and the corresponding callback is then called, and removed from the list of callbacks waiting for response . each callback is programmed to look for possible known GDB reactions (per the GDB/MI protocol), which could be one or more of: - nothing (a normal reaction in many cases) - some output, like if the command requests the list of threads - an error message - free text message . these texts are (AFAIR) looked for in the process buffer, where the filter puts them