public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/28412] New: syscall that writes memory does not trigger hardware watchpoint.
@ 2021-10-02 19:16 yyc1992 at gmail dot com
  2021-10-09 11:25 ` [Bug gdb/28412] " ssbssa at sourceware dot org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: yyc1992 at gmail dot com @ 2021-10-02 19:16 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28412

            Bug ID: 28412
           Summary: syscall that writes memory does not trigger hardware
                    watchpoint.
           Product: gdb
           Version: 11.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Debugging the following program (on x64). (Compile with -O0 -ggdb3 to make it
easy to set a watch at the beginning).

```
#include <unistd.h>
#include <stdio.h>

int main()
{
    char c = 0;
    printf("%d\n", c);
    read(0, &c, 1);
    printf("%d\n", c);

    return 0;
}
```

When a watchpoint is set on `c` with `watch -l c` or `watch c`, the value is
changed by `read` without triggering the watch point. Turning off hardware
watchpoint fixes the issue. Seems that when hardware watch point is used,
checks needs to be added around syscalls to see if they modify memory?

(Initially noticed from `ptrace` but it seems that other syscalls have the same
problem.) I didn't find any document saying syscall modifying memory needs to
be watched differently and since it works without hardware watchpoint I assume
this is a bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug gdb/28412] syscall that writes memory does not trigger hardware watchpoint.
  2021-10-02 19:16 [Bug gdb/28412] New: syscall that writes memory does not trigger hardware watchpoint yyc1992 at gmail dot com
@ 2021-10-09 11:25 ` ssbssa at sourceware dot org
  2021-10-09 17:26 ` simark at simark dot ca
  2022-03-06 17:15 ` tromey at sourceware dot org
  2 siblings, 0 replies; 4+ messages in thread
From: ssbssa at sourceware dot org @ 2021-10-09 11:25 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28412

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug gdb/28412] syscall that writes memory does not trigger hardware watchpoint.
  2021-10-02 19:16 [Bug gdb/28412] New: syscall that writes memory does not trigger hardware watchpoint yyc1992 at gmail dot com
  2021-10-09 11:25 ` [Bug gdb/28412] " ssbssa at sourceware dot org
@ 2021-10-09 17:26 ` simark at simark dot ca
  2022-03-06 17:15 ` tromey at sourceware dot org
  2 siblings, 0 replies; 4+ messages in thread
From: simark at simark dot ca @ 2021-10-09 17:26 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28412

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
(In reply to Yichao Yu from comment #0)
> When a watchpoint is set on `c` with `watch -l c` or `watch c`, the value is
> changed by `read` without triggering the watch point. Turning off hardware
> watchpoint fixes the issue. Seems that when hardware watch point is used,
> checks needs to be added around syscalls to see if they modify memory?

That sounds doable (although at a cost).  GDB uses PTRACE_SYSCALL to cause the
program to stop on syscall entry only if the user has set up some syscall
catchpoints.  But it could also be enabled if the user has some hardware
watchpoints set.  When a thread exits, we would get an event, and we could
check all watchpoints, see if the memory they watch has changed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug gdb/28412] syscall that writes memory does not trigger hardware watchpoint.
  2021-10-02 19:16 [Bug gdb/28412] New: syscall that writes memory does not trigger hardware watchpoint yyc1992 at gmail dot com
  2021-10-09 11:25 ` [Bug gdb/28412] " ssbssa at sourceware dot org
  2021-10-09 17:26 ` simark at simark dot ca
@ 2022-03-06 17:15 ` tromey at sourceware dot org
  2 siblings, 0 replies; 4+ messages in thread
From: tromey at sourceware dot org @ 2022-03-06 17:15 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=28412

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org
   Last reconfirmed|                            |2022-03-06
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-03-06 17:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-02 19:16 [Bug gdb/28412] New: syscall that writes memory does not trigger hardware watchpoint yyc1992 at gmail dot com
2021-10-09 11:25 ` [Bug gdb/28412] " ssbssa at sourceware dot org
2021-10-09 17:26 ` simark at simark dot ca
2022-03-06 17:15 ` tromey at sourceware dot org

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).