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#63084: 30.0.50; gud: set breakpoint while program is running Date: Mon, 29 May 2023 14:45:22 +0300 Message-ID: <83v8gbgy3x.fsf@gnu.org> References: <874jp3n52b.fsf@home.mail-host-address-is-not-set> <838refuqa8.fsf@gnu.org> <83wn1zt1tu.fsf@gnu.org> <83bkizjpcp.fsf@gnu.org> <83wn1lfzxm.fsf@gnu.org> <83r0r1hvnn.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19838"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63084@debbugs.gnu.org, kbrown@cornell.edu To: TatriX Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 29 13:45: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 1q3bJU-0004qs-2N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 May 2023 13:45:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3bJA-0004FF-Vt; Mon, 29 May 2023 07:45:05 -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 1q3bJ8-0004F5-IK for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 07:45: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 1q3bJ8-0003au-AC for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 07:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q3bJ8-0004TD-5g for bug-gnu-emacs@gnu.org; Mon, 29 May 2023 07:45: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: Mon, 29 May 2023 11:45: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.168536069117152 (code B ref 63084); Mon, 29 May 2023 11:45:02 +0000 Original-Received: (at 63084) by debbugs.gnu.org; 29 May 2023 11:44:51 +0000 Original-Received: from localhost ([127.0.0.1]:57256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3bIx-0004SZ-0c for submit@debbugs.gnu.org; Mon, 29 May 2023 07:44:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3bIv-0004SI-J7 for 63084@debbugs.gnu.org; Mon, 29 May 2023 07:44:50 -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 1q3bIp-0003Wx-Fv; Mon, 29 May 2023 07:44:43 -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=RFLKIfG2ifkO+VPz7k3HBcFwvf5ltf/co3KoeE5ZvYQ=; b=qJFGUHiJOHpz EGNzwHQJ1/cG7rwGdtxztGBnC38Ilr33kSYGkU/6vIGb4smF2J6FSZQC0ouNRD2cH4gAzllRi43Cg g9ARU0yqgaBOIqIE9mX6BLtHMq0tbKVOS8VDiH3f0SXBlpdh1lnIwDw0e+gB88RTAn8c0EJaqRahL yBtLmckqo3qbD4qzV2F04y2R2nWaN7JxGIcy0FNdMBgkzUoQ3i2FZg2c6ciuXPQhz3ZHQonZRJXi0 OHXOfJEWIoVAqh164VoToRgW6d71J0KgCKiSWVUBj2XMOPsSVdjuVhhkuhGslTpsb6sqdKogaP2Vt EDV3swTrvetK4n822cInNw==; 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 1q3bIp-00067d-1l; Mon, 29 May 2023 07:44:43 -0400 In-Reply-To: (message from TatriX on Sun, 28 May 2023 23:10:21 +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:262567 Archived-At: > From: TatriX > Date: Sun, 28 May 2023 23:10:21 +0200 > Cc: 63084@debbugs.gnu.org, kbrown@cornell.edu > > One feature I'm really missing is a variable watcher. > > There's a locals view which is useful sometimes, but gets messy when > there are handfull of variables in scope. Then there's a speedbar, > but as far as I can tell it's impossible to make it into a regular > window, which means it and cannot participate in my regular emacs > window workflow, which is sub-optimal. I'm not sure I understand: how does using Speedbar interfere with your workflow? > But the biggest issue with it is that it forgets what was added to > it on every program restart, making it pretty much unusable for my > needs. I'm not sure how can this work otherwise: watchpoints are usually context-dependent, and are automatically deleted when their component variables go out of scope. How would you know when to re-apply watchpoint settings when you re-run the program? You must be in the correct call-stack frame to be able to do that, or else all you get as an error from GDB. The way to automate re-application of watchpoints is to create one or more breakpoints, at suitable locations in the program, and have the "commands" of those breakpoints insert watchpoints, then continue the program. This is usually done in a .gdbinit file (or some other script file read by GDB), and I'm not sure I understand how you can do that programmatically, since Emacs is not really aware of GDB call-stack frames. > I've played a bit with gdb-mi and managed to make something that > somewhat works. Please check a screenshot in the attachment. > > I can add variables to watch via the minibuffer. They get updated in > the *gdb-watch* window through `-data-evaluate-expression` in the > `gdb-stopped-functions` hook. > > I've also started looking at "GDB/MI Variable Objects"(1) which looks > like a proper way to add that functionality. But it requires a bit > more work. AFAIK, Variable Objects cannot be replacements for watchpoints, since GDB must actively poll for updates of the values, as opposed to watchpoints, whose changes cause the program to stop. > How do you feel about having something similar in gdb-mi? It would be a useful addition, but I'd expect it to be easily doable by reusing what we currently have (I'm not sure I understand why we currently insist on Speedbar for these displays). Anyway, this should be discussed as a separate feature request, not as part of this bug report.