unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: TatriX <tatrics@gmail.com>
Cc: 63084@debbugs.gnu.org, kbrown@cornell.edu
Subject: bug#63084: 30.0.50; gud: set breakpoint while program is running
Date: Mon, 29 May 2023 14:45:22 +0300	[thread overview]
Message-ID: <83v8gbgy3x.fsf@gnu.org> (raw)
In-Reply-To: <CAG7LdX7=dWzvdvR3f5fKYf0s54VMMqmEyLp+T9S5uBsZKKxT6g@mail.gmail.com> (message from TatriX on Sun, 28 May 2023 23:10:21 +0200)

> From: TatriX <tatrics@gmail.com>
> 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.





  reply	other threads:[~2023-05-29 11:45 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  2:21 bug#64186: Patch: Suppress deprecated '-gdb-set target-async' warning message in gdb-mi.el Wang Diancheng
2023-06-20  7:24 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-20  9:25   ` Wang Diancheng
2023-06-20  9:43     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-20 11:55     ` Eli Zaretskii
2023-06-21  6:49       ` Wang Diancheng
2023-06-21 13:12         ` Eli Zaretskii
2023-06-28  3:51           ` Wang Diancheng
2023-06-29  6:09             ` Eli Zaretskii
2023-06-30  7:08               ` Wang Diancheng
2023-07-06  7:10                 ` Eli Zaretskii
2023-04-25 19:18                   ` bug#63084: 30.0.50; gud: set breakpoint while program is running tatrics
2023-04-26  6:10                     ` Eli Zaretskii
2023-04-26  8:48                       ` TatriX
2023-04-26  9:44                         ` Eli Zaretskii
2023-04-26 11:19                           ` Eli Zaretskii
2023-04-26 11:49                             ` TatriX
2023-05-05  5:52                             ` Eli Zaretskii
2023-05-05  5:53                           ` Eli Zaretskii
2023-05-05  7:15                             ` TatriX
2023-05-06 11:43                               ` Eli Zaretskii
2023-05-27 21:22                                 ` TatriX
2023-05-28  5:28                                   ` Eli Zaretskii
2023-05-28 21:10                                     ` TatriX
2023-05-29 11:45                                       ` Eli Zaretskii [this message]
     [not found]                     ` <handler.63084.D64186.168862741914107.notifdone@debbugs.gnu.org>
2023-07-11  7:31                       ` bug#63084: closed (Re: bug#64186: Patch: Suppress deprecated '-gdb-set target-async' warning message in gdb-mi.el) TatriX
2023-07-11 12:24                         ` Eli Zaretskii
2023-07-11 15:30                           ` TatriX
2023-07-11 15:56                             ` Eli Zaretskii
2023-07-11 17:49                               ` TatriX
2023-07-13  6:26                                 ` Eli Zaretskii
2023-07-07  6:25                   ` bug#64186: Patch: Suppress deprecated '-gdb-set target-async' warning message in gdb-mi.el Wang Diancheng
2023-07-07  6:42                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83v8gbgy3x.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63084@debbugs.gnu.org \
    --cc=kbrown@cornell.edu \
    --cc=tatrics@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).