From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustaf Waldemarson Newsgroups: gmane.emacs.bugs Subject: bug#62697: gdb-mi.el: Change target-async to mi-async Date: Fri, 7 Apr 2023 12:36:31 +0200 Message-ID: References: <835ya9qgox.fsf@gnu.org> <79ec3700-02ab-7574-1411-dfef0ec5eb7f@gmail.com> <83h6tsp5s1.fsf@gnu.org> <83bkk0ouhx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e0b44605f8bc99a6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17426"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , 62697@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 07 12:37:08 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 1pkjSt-0004LI-OJ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 07 Apr 2023 12:37:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pkjSp-00043w-2h; Fri, 07 Apr 2023 06:37:03 -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 1pkjSo-00043n-6U for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:37:02 -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 1pkjSn-0001vZ-Um for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:37:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pkjSn-0008A1-Ha for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2023 06:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustaf Waldemarson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Apr 2023 10:37: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.168086381031352 (code B ref 62697); Fri, 07 Apr 2023 10:37:01 +0000 Original-Received: (at 62697) by debbugs.gnu.org; 7 Apr 2023 10:36:50 +0000 Original-Received: from localhost ([127.0.0.1]:55732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkjSb-00089b-M3 for submit@debbugs.gnu.org; Fri, 07 Apr 2023 06:36:50 -0400 Original-Received: from mail-yw1-f173.google.com ([209.85.128.173]:43905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pkjSa-00089O-DL for 62697@debbugs.gnu.org; Fri, 07 Apr 2023 06:36:49 -0400 Original-Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-5491fa028adso292499157b3.10 for <62697@debbugs.gnu.org>; Fri, 07 Apr 2023 03:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680863803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=W/v9pZvpZkCNT+QBFRyij4nH6l3DlHD2JZJ3GxBV/M0=; b=JSjO6qw2Y8IvBxpsofe+TrR8cHcVndyRozMY+dhUkZfDUz0rWXMF/Qi0riA4r9KYxV TibxlHFtzMw/5sbZJvGwIzKVN91evDOwJrQpNoMBrFxSQVrEPVBTkPdsOYaliW39W1No KZtjbX63tjWzOtDalyN2J5TCptlMcN+BPfq3t60foJnwjNU/PSc4Am7OMGJbECRPwu+P jZ7gqH22fwzOJi5c813y9+pf33d6bIFDK9H7v0/W2hZKdBK02U06vr+VNL2uYgy0U7Om WgAxBRDyT8VHQ6sWiIwDFTAF3VPAd4fEG6yzYoeqvNsr/hCss8EVJsITOvK7EO9+e5m9 1jeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680863803; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W/v9pZvpZkCNT+QBFRyij4nH6l3DlHD2JZJ3GxBV/M0=; b=SSu45a6hi50jAXn1tqJcx1cvIz5OWL7R79zcTeHJr/DOlcqMkvGGdgHEJuPv1uDk/c 6e0CDde2gHp5xTBNNFPDoeBYNJ4cqowHYkQ/zbR3uRbrtazgTOtr7EfcPK5BrAR1q1EE qiirmthEiq3fn6z59uskCT8QpE1te5iF2seNV4IYhsya+YubP2kfxtW1SvSUtwbfqiTw R8MDS8WNMzXhD3JBmCP7HODEGWqyHCE8s2f4VjdFzvTWpvfCZ9AjBcxSBwGC+Anc1OGx ACVzVhPZxVhLWfEs4XCtcLT/gh/HOmgUfYQaYhnewWGRc7RmAdKbfYuyFoJhU8BthFJH 6hbA== X-Gm-Message-State: AAQBX9fpCrt08705YJqq6jiaejBYbA9ZT4EVmjBsC0l4T4iJlpIxHzL1 qxCvapMlA3gDHgr0atmg2ygSMdwta9zxtgcm/I0= X-Google-Smtp-Source: AKy350bUbdNCVTioWWReCkW8nj+Kj9fX5061K6qOMQsEmli7nPXh6bnSRybVtmtduFBZy8jHX+36wLKayajkq2mm7qM= X-Received: by 2002:a81:ac44:0:b0:544:5042:324a with SMTP id z4-20020a81ac44000000b005445042324amr883255ywj.3.1680863802732; Fri, 07 Apr 2023 03:36:42 -0700 (PDT) In-Reply-To: <83bkk0ouhx.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:259375 Archived-At: --000000000000e0b44605f8bc99a6 Content-Type: text/plain; charset="UTF-8" Filtering the message is probably easy, but as Jim pointed out, it will probably have unintended consequences later on. Besides, extracting the version could enable a lot of different things down the line. 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. >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))) (defun gdb-version-handler () "Set the version of gdb currently being used." (message "Searching for GDB version...") (goto-char (point-min)) (print (buffer-substring-no-properties (point-min) (point-max))) (with-current-buffer (gdb-get-buffer 'gdb-partial-output-buffer) (goto-char (point-min)) (print (buffer-substring-no-properties (point-min) (point-max))) (when (re-search-forward "GNU gdb (GDB) \\(.+\\)" nil t) (message "Attempting to retrieve GDB version: %s" (match-string 1)) (setq gdb-version (match-string 1))))) I also tried to change the buffer in the `gdb-version-handler`, but that didn't actually change anything. Am I making some wrong assumption here? To me at least, it does not make sense that these are empty. Best regards, Gustaf Den fre 7 apr. 2023 kl 12:29 skrev Eli Zaretskii : > > Date: Fri, 7 Apr 2023 00:25:03 -0700 > > Cc: 62697@debbugs.gnu.org, gustaf.waldemarson@gmail.com > > From: Jim Porter > > > > On 4/6/2023 11:26 PM, Eli Zaretskii wrote: > > > > > > 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? > > I don't know. > > > Would adding another layer of callback make it any worse? > > I don't know. > > > Maybe so, but if we're worried about the latter, then couldn't we do > > something like: > > I don't know! It will take someone who knows a lot more than I do > about both GDB/MI and gdb-mi.el to tell, and the changes need to be > tested with many different versions of GDB. Feel free to do that and > see if those changes are benign, and then we can install them. > Failing that, given that we don't have an active enough maintainer of > gdb-mi.el on board, I feel that suppressing the annoying message is a > much more easy way out. > > > Assuming handlers are called in the same order as their inputs are sent, > > They are called in the order in which responses for inputs are > received, not in the order these inputs are sent. I don't think these > are the same orders, at least they aren't guaranteed to be. You can > see this by yourself if you enable the gdb-mi debug mode (each > response is tagged with the number of the corresponding input command, > and those numbers are given to commands by gdb-mi.el in the order it > sends the commands). > > > 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. > > I'm not even sure this will be removed at all. It certainly won't be > removed soon, as they just recently started issuing a warning. For > example, the annotations feature of GDB, use by "M-x gud-gdb", is > still being supported, although it became deprecated as soon as GDB/MI > was added to GDB. > > > 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. > > I agree. But if adding that means dealing with tricky > timing-dependent and version-dependent bugs, I prefer to use a less > radical solution, even if it's less clean and less future-proof. > > Btw, as an easy alternative, we could add a defcustom whose value > would be the minimum supported value of GDB. Then users could set it > to, say, 7.8.0, to force gdb-mi.el to use mi-async, and by that avoid > the annoyance. This could even go into Emacs 29. > --000000000000e0b44605f8bc99a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Filtering the message is probably easy, but as Jim po= inted out, it will probably
have unintended consequences lat= er on. Besides, extracting the version could
enable a lot of diff= erent things down the line.

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 o= f these
"handlers" are actually working as intended.

From what I can see, the handlers scan the current b= uffer (which one is that anyways?)
to determine whether to do som= e operations. However, adding some prints to
these handlers revea= l that they seem to always be empty:

(defun gd= b-non-stop-handler ()
=C2=A0 (goto-char (point-min))
=C2=A0 (print (b= uffer-substring-no-properties (point-min) (point-max)))
=C2=A0 (if (re-s= earch-forward "No symbol" nil t)
=C2=A0 =C2=A0 =C2=A0 (progn (message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"This version of GDB = doesn't support non-stop mode.=C2=A0 Turning it off.")
(setq g= db-non-stop nil)
(setq gdb-supports-non-stop nil))
=C2=A0 =C2=A0 (se= tq gdb-supports-non-stop t)
=C2=A0 =C2=A0 (gdb-input "-gdb-set mi-a= sync on" 'ignore)
=C2=A0 =C2=A0 (gdb-input "-list-target-f= eatures" 'gdb-check-mi-async)))

(defu= n gdb-version-handler ()
=C2=A0 "Set the version of gdb currently b= eing used."
=C2=A0 (message "Searching for GDB version..."= ;)
=C2=A0 (goto-char (point-min))
=C2=A0 (print (buffer-substring-no-= properties (point-min) (point-max)))
=C2=A0 (with-current-buffer (gdb-ge= t-buffer 'gdb-partial-output-buffer)
=C2=A0 =C2=A0 (goto-char (point= -min))
=C2=A0 =C2=A0 (print (buffer-substring-no-properties (point-min) = (point-max)))
=C2=A0 =C2=A0 (when (re-search-forward "GNU gdb (GDB)= \\(.+\\)" nil t)
=C2=A0 =C2=A0 =C2=A0 (message
=C2=A0 =C2=A0 = =C2=A0 =C2=A0"Attempting to retrieve GDB version: %s" (match-stri= ng 1))
=C2=A0 =C2=A0 =C2=A0 (setq gdb-version (match-string 1)))))
=

I also tried to change the buffer in the `gdb-version-h= andler`, but that didn't
actually change anything. Am I makin= g some wrong assumption here? To me
at least, it does not make se= nse that these are empty.

Best regards,
= Gustaf

Den fre 7 apr. 2023 kl 12:29 skrev Eli Zaretskii <eliz@gnu.org>:
> Date: Fri, 7 Apr 2023 00:25:03 -0700
> Cc: 62697@d= ebbugs.gnu.org, gustaf.waldemarson@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
>
> On 4/6/2023 11:26 PM, Eli Zaretskii wrote:
> >
> >=C2=A0 =C2=A0 The frontend may specify a preference for asynchrono= us execution
> >=C2=A0 =C2=A0 using the '-gdb-set mi-async 1' command, whi= ch should be emitted
> >=C2=A0 =C2=A0 before either running the executable or attaching to= the target.
> >
> > If GDB is invoked with, e.g., "gdb -p PID", then we nee= d 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, th= e one
> for "-gdb-set non-stop 1". Is this code already violating GD= B's rules?

I don't know.

> Would adding another layer of callback make it any worse?

I don't know.

> Maybe so, but if we're worried about the latter, then couldn't= we do
> something like:

I don't know!=C2=A0 It will take someone who knows a lot more than I do=
about both GDB/MI and gdb-mi.el to tell, and the changes need to be
tested with many different versions of GDB.=C2=A0 Feel free to do that and<= br> see if those changes are benign, and then we can install them.
Failing that, given that we don't have an active enough maintainer of gdb-mi.el on board, I feel that suppressing the annoying message is a
much more easy way out.

> Assuming handlers are called in the same order as their inputs are sen= t,

They are called in the order in which responses for inputs are
received, not in the order these inputs are sent.=C2=A0 I don't think t= hese
are the same orders, at least they aren't guaranteed to be.=C2=A0 You c= an
see this by yourself if you enable the gdb-mi debug mode (each
response is tagged with the number of the corresponding input command,
and those numbers are given to commands by gdb-mi.el in the order it
sends the commands).

> 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 <= br> > then gdb-mi.el breaks.

I'm not even sure this will be removed at all.=C2=A0 It certainly won&#= 39;t be
removed soon, as they just recently started issuing a warning.=C2=A0 For example, the annotations feature of GDB, use by "M-x gud-gdb", is=
still being supported, although it became deprecated as soon as GDB/MI
was added to GDB.

> 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.

I agree.=C2=A0 But if adding that means dealing with tricky
timing-dependent and version-dependent bugs, I prefer to use a less
radical solution, even if it's less clean and less future-proof.

Btw, as an easy alternative, we could add a defcustom whose value
would be the minimum supported value of GDB.=C2=A0 Then users could set it<= br> to, say, 7.8.0, to force gdb-mi.el to use mi-async, and by that avoid
the annoyance.=C2=A0 This could even go into Emacs 29.
--000000000000e0b44605f8bc99a6--