public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix setting watchpoints when current thread is running (PR gdb/31521)
Date: Thu, 21 Mar 2024 18:38:35 +0000	[thread overview]
Message-ID: <dab83033-88ce-4d42-9129-74615c7b88f2@palves.net> (raw)
In-Reply-To: <86o7b71pe0.fsf@gnu.org>

On 2024-03-21 17:11, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> Date: Thu, 21 Mar 2024 16:43:31 +0000
>>
>> Currently, when the current thread is running, you can print global
>> variables.  However, if you try to set a watchpoint on the same
>> globals, GDB errors out, complaining that the selected thread is
>> running.  Like so:
>>
>>  (gdb) c&
>>  Continuing.
>>  (gdb) p global
>>  $1 = 1098377287
>>  (gdb) watch global
>>  Selected thread is running.
>>
>> This patch makes setting the watchpoint work.  The problem is that
>> update_watchpoint calls get_selected_frame unconditionally.  We can
>> skip it if the watchpoint expression is only watching globals.
> 
> What does this mean in practice?  E.g., suppose GDB sets the
> watchpoint when the selected thread is changing the variable to be
> watched -- will the thread stop or won't it?  IOW, I don't understand
> what happens with programming the debug registers while some thread is
> running.

GDB very briefly temporarily pauses all threads to program the debug registers,
and immediately resumes them.  But that is not user visible.  That part actually
always worked -- we needed to make that work for when the current thread you have
selected is stopped, but there are other threads in the program that are
running -- we need to arm the debug registers of those running threads too, so
the target backend needs to know to pause any running thread.

We just never reached that code when the _selected_ thread is running because very early
in the "watch" code, we tried to get information about the current frame, while when the
thread is running, there is no frame object to consult, thus GDB threw an error.

> 
>> New NEWS blurb added.  I don't think we need to change anything in the
>> manual.
> 
> If this is deemed a bugfix, then we don't need to say anything in
> NEWS, either, IMO.

OK, I was actually borderline with calling it a bug fix or a new feature.
I will just drop NEWS then.

Thanks!

Pedro Alves

  reply	other threads:[~2024-03-21 18:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 16:43 Pedro Alves
2024-03-21 17:11 ` Eli Zaretskii
2024-03-21 18:38   ` Pedro Alves [this message]
2024-04-12 17:57     ` Pedro Alves
2024-05-07  8:46       ` Tom de Vries
2024-05-07 10:30         ` Pedro Alves

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

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

  git send-email \
    --in-reply-to=dab83033-88ce-4d42-9129-74615c7b88f2@palves.net \
    --to=pedro@palves.net \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /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.
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).