From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: TatriX Newsgroups: gmane.emacs.bugs Subject: bug#63084: 30.0.50; gud: set breakpoint while program is running Date: Wed, 26 Apr 2023 13:49:11 +0200 Message-ID: References: <874jp3n52b.fsf@home.mail-host-address-is-not-set> <838refuqa8.fsf@gnu.org> <83wn1zt1tu.fsf@gnu.org> <83mt2uubzw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003f76ed05fa3bd4ac" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28746"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63084@debbugs.gnu.org, Ken Brown To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 26 13:50:34 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 1prdfO-0007JJ-EI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Apr 2023 13:50:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1prdf8-00055S-5G; Wed, 26 Apr 2023 07:50:18 -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 1prdes-00051p-Up for bug-gnu-emacs@gnu.org; Wed, 26 Apr 2023 07:50: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 1prdes-0000mB-D1 for bug-gnu-emacs@gnu.org; Wed, 26 Apr 2023 07:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1prdes-0000Hd-90 for bug-gnu-emacs@gnu.org; Wed, 26 Apr 2023 07:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: TatriX Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Apr 2023 11:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63084 X-GNU-PR-Package: emacs Original-Received: via spool by 63084-submit@debbugs.gnu.org id=B63084.16825097651033 (code B ref 63084); Wed, 26 Apr 2023 11:50:02 +0000 Original-Received: (at 63084) by debbugs.gnu.org; 26 Apr 2023 11:49:25 +0000 Original-Received: from localhost ([127.0.0.1]:54437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdeG-0000Gb-SA for submit@debbugs.gnu.org; Wed, 26 Apr 2023 07:49:25 -0400 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:56448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prdeC-0000GL-PO for 63084@debbugs.gnu.org; Wed, 26 Apr 2023 07:49:23 -0400 Original-Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-51b661097bfso5390378a12.0 for <63084@debbugs.gnu.org>; Wed, 26 Apr 2023 04:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682509755; x=1685101755; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T1DWUl2ZEfInkSt5lHy029Q4W/gS7qNAouPrZIDfq9s=; b=JRwIDIlq3a4P84YBEub6k0ZGRI0L9aXcslYGrHdh3M7jE/emYk118IUPVV5O6xXCjO hme1F76JdPDyjpF/NQ9tOHRPx2XxWHd/WBqsi3MQoN2/vbZ8KfdE/SjE4f5EemEtV2Hb upNWiuB3NJF7jEyBCPx2N/fG0Q8xeypEDiC8oNI4FDzAWL7fT+DKB7owC2VPbkjUBxCX aXPMrMt5By59vsKw6KQtUt1pyUk8Y8wVpP2kvwEajenUylXCh2SYm/j94HRfMeLV+D3i xjdjPI+e3y2hTbmRhyunudn7LChjtJ+CE+ytDxCh24wf8wHyHGuyeD7nL25jJDH8G2XO I/xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682509755; x=1685101755; 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=T1DWUl2ZEfInkSt5lHy029Q4W/gS7qNAouPrZIDfq9s=; b=kamAXZrcHRM9p4B5CvFI1SO4U3iel+1tMZxDJ5B7K+jusltrVIkYxBl68qthyhv8BU SAhlhi12gCQl02z7joCdBEnVCK5JJabYEAUHgRjbK4MJkfh+Vm+Tr7wSTlp9DmKjZz5d S88DoP1+2TYSp7yLB7vVey1BMf9oeYNezLTH0MXm9n0JfYCFheq2urI02rX7TrgGUQ9w XjFd7IrhuM3cSH/SJdiEaJENw5Rj+kYg1V9kdPAXU7Opk3SzFfdSbHadjjD6CZYaqYEA Rzxuo0GWumNG4ubx61QAv9gOb2w9A6jGWSMuwbI9IEbnllQ5UVP9xvmX/ky/uMnvMzXT WYqA== X-Gm-Message-State: AAQBX9fzGoeoyLlH1PYIY3INMHDWhKQ1mleKSGxkyKP94pSEz+RhTkrD Z7DkopLEu1vrEPd3JIT7yP23pch5yy5qAFcjJWk= X-Google-Smtp-Source: AKy350ZBSN3Hs15BiWilJQgrsNREfpIL55y0nIUgYnCjsPWv27hcYOncLc96oG/4hZv/PkMhowFZ6Y4tO5P6ravOjBA= X-Received: by 2002:a17:90a:bd94:b0:249:842d:312f with SMTP id z20-20020a17090abd9400b00249842d312fmr20594409pjr.4.1682509754495; Wed, 26 Apr 2023 04:49:14 -0700 (PDT) In-Reply-To: <83mt2uubzw.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:260670 Archived-At: --0000000000003f76ed05fa3bd4ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > What is the value of gdb-running and of gdb-non-stop after you "run&" > the program? ELISP> gdb-running *** Eval error *** Symbol=E2=80=99s value as variable is void: gdb-running ELISP> gud-running t ELISP> gdb-non-stop nil On Wed, Apr 26, 2023 at 1:19=E2=80=AFPM Eli Zaretskii wrote: > > Cc: 63084@debbugs.gnu.org > > Date: Wed, 26 Apr 2023 12:44:29 +0300 > > From: Eli Zaretskii > > > > > From: TatriX > > > Date: Wed, 26 Apr 2023 10:48:53 +0200 > > > Cc: 63084@debbugs.gnu.org > > > > > > Oh, sorry. I tried on a different machine, and realized one have to > use "run&". > > > > > > So, here's what I did: > > > > > > $ cat main.c > > > #include > > > #include > > > > > > int main(void) { > > > for (int i =3D 0; ; i++) { > > > printf("%d\n", i); > > > sleep(1); > > > } > > > } > > > > > > $ gcc -g -o break main.c > > > $ emacs -Q main.c > > > M-x gdb RET > > > # in *gud-break*, NOTE it's "run&" > > > (gdb) run& > > > # in main.c > > > (goto-line 6) > > > (gud-break 1) ; or C-x C-a C-b > > > # nothing happens > > > M-: (gud-call "break 6") RET > > > # breakpoint is set and process execution is paused on hitting that > breakpoint > > > > What is the value of gdb-running and of gdb-non-stop after you "run&" > > the program? > > Ken, could you please take a look at this bug report? AFAICT, it has > something to do with the code you changed some 11 years ago (see > bug#9878). > > Basically, what "M-x gdb" now does is send the "-gdb-set non-stop 1" > command, then, when we get a valid response for it, it sends the > "-gdb-set target-async 1" command. So far so good, but when we get > the response for the latter, we send the "-list-target-features" > command and expect it to report "async" as one of the features, and if > not, we decide that non-stop mode is not supported. > > My testing indicates that -list-target-features will only report > "async" after we run the program or attach to a process. So we are > (almost) always disabling the non-stop mode, which doesn't seem right > to me. > > So I'm interested to know how you tested this particular addition of > the -list-target-features command back then (if you remember). Also, > what happens today when you start "M-x gdb" with a modern version of > GDB that does support target-async and non-stop mode. > > The root cause that "C-x C-a C-b" doesn't work in the OP is that > gud-break (and any other command defined via gud-def) does nothing > when gud-running is non-nil. This needs to be changed if we are > running the program in the background, but the question is how to know > that reliably, and that is related -list-target-features, among other > things. > > TIA > --0000000000003f76ed05fa3bd4ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What is the value of gdb-running and of gdb-non-= stop after you "run&"
> the program?

ELISP> gdb-running
*** Eval error *** =C2=A0Symbol=E2=80=99s= value as variable is void: gdb-running
ELISP> gud-running
t
EL= ISP> gdb-non-stop
nil

On Wed, Apr 26, 2023 at 1:19=E2=80=AFPM Eli Zare= tskii <eliz@gnu.org> wrote:
> Cc: 63084@debbugs.gnu.org > Date: Wed, 26 Apr 2023 12:44:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: TatriX <tatrics@gmail.com>
> > Date: Wed, 26 Apr 2023 10:48:53 +0200
> > Cc: 63= 084@debbugs.gnu.org
> >
> > Oh, sorry. I tried on a different machine, and realized one have = to use "run&".
> >
> > So, here's what I did:
> >
> > $ cat main.c
> >=C2=A0 =C2=A0 =C2=A0#include <stdio.h>
> >=C2=A0 =C2=A0 =C2=A0#include <unistd.h>
> >
> >=C2=A0 =C2=A0 =C2=A0int main(void) {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (int i =3D 0; ; i++) {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0printf("%d\n&= quot;, i);
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sleep(1);
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0}
> >
> > $ gcc -g -o break main.c
> > $ emacs -Q main.c
> > M-x gdb RET
> > # in *gud-break*, NOTE it's "run&"
> > (gdb) run&
> > # in main.c
> > (goto-line 6)
> > (gud-break 1) ; or C-x C-a C-b
> > # nothing happens
> > M-: (gud-call "break 6") RET
> > # breakpoint is set and process execution is paused on hitting th= at breakpoint
>
> What is the value of gdb-running and of gdb-non-stop after you "r= un&"
> the program?

Ken, could you please take a look at this bug report?=C2=A0 AFAICT, it has<= br> something to do with the code you changed some 11 years ago (see
bug#9878).

Basically, what "M-x gdb" now does is send the "-gdb-set non= -stop 1"
command, then, when we get a valid response for it, it sends the
"-gdb-set target-async 1" command.=C2=A0 So far so good, but when= we get
the response for the latter, we send the "-list-target-features"<= br> command and expect it to report "async" as one of the features, a= nd if
not, we decide that non-stop mode is not supported.

My testing indicates that -list-target-features will only report
"async" after we run the program or attach to a process.=C2=A0 So= we are
(almost) always disabling the non-stop mode, which doesn't seem right to me.

So I'm interested to know how you tested this particular addition of the -list-target-features command back then (if you remember).=C2=A0 Also,<= br> what happens today when you start "M-x gdb" with a modern version= of
GDB that does support target-async and non-stop mode.

The root cause that "C-x C-a C-b" doesn't work in the OP is t= hat
gud-break (and any other command defined via gud-def) does nothing
when gud-running is non-nil.=C2=A0 This needs to be changed if we are
running the program in the background, but the question is how to know
that reliably, and that is related -list-target-features, among other
things.

TIA
--0000000000003f76ed05fa3bd4ac--