public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH] Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)
Date: Mon, 21 Mar 2022 17:28:59 +0000	[thread overview]
Message-ID: <0e99645e-f435-7d6e-fd6e-a474cdb151e4@palves.net> (raw)
In-Reply-To: <20220307165600.906162-1-pedro@palves.net>

On 2022-03-07 16:56, Pedro Alves wrote:
> If GDB reports a watchpoint hit, and then the next event is not
> TARGET_WAITKIND_STOPPED, but instead some event for which there's a
> catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly
> thinks the watchpoint triggered.  Vis, using foll-fork.c:
> 
>   (gdb) awatch v
>   Hardware access (read/write) watchpoint 2: v
>   (gdb) catch fork
>   Catchpoint 3 (fork)
>   (gdb) c
>   Continuing.
> 
>   Hardware access (read/write) watchpoint 2: v
> 
>   Old value = 0
>   New value = 5
>   main () at gdb.base/foll-fork.c:16
>   16        pid = fork ();
>   (gdb)
>   Continuing.
> 
>   Hardware access (read/write) watchpoint 2: v      <<<<
>                                                     <<<< these lines are spurious
>   Value = 5                                         <<<<
> 
>   Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49
>   49      arch-fork.h: No such file or directory.
>   (gdb)
> 
> The problem is that when we handle the fork event, nothing called
> watchpoints_triggered before calling bpstat_stop_status.  Thus, each
> watchpoint's watchpoint_triggered field was still set to
> watch_triggered_yes from the previous (real) watchpoint stop.
> watchpoint_triggered is only current called in the handle_signal_stop
> path, when handling TARGET_WAITKIND_STOPPED.
> 
> This fixes it by adding watchpoint_triggered calls in the other events
> paths that call bpstat_stop_status.  But instead of adding them
> explicitly, it adds a new function bpstat_stop_status_nowatch that
> wraps bpstat_stop_status and calls watchpoint_triggered, and then
> replaces most calls to bpstat_stop_status with calls to
> bpstat_stop_status_nowatch.
> 
> This required constifying watchpoints_triggered.
> 
> New test included, which fails without the fix.
> 
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621
> 
> Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c

I've merged this to master.

Pedro Alvse

      reply	other threads:[~2022-03-21 17:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 16:56 Pedro Alves
2022-03-21 17:28 ` Pedro Alves [this message]

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=0e99645e-f435-7d6e-fd6e-a474cdb151e4@palves.net \
    --to=pedro@palves.net \
    --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).