public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/27422] New: Warn when degrading hw -> sw watchpoint
Date: Mon, 15 Feb 2021 14:03:57 +0000	[thread overview]
Message-ID: <bug-27422-4717@http.sourceware.org/bugzilla/> (raw)

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

            Bug ID: 27422
           Summary: Warn when degrading hw -> sw watchpoint
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case test.c:
...
$ cat -n test.c
     1  #include <stdio.h>
     2  #include <stdlib.h>
     3  volatile int a = 1;
     4  volatile int b = 1;
     5       
     6  int main (void)
     7  {
     8    volatile unsigned long long int i;
     9    a = 2;
    10    for (i = 0; i < 1000000000; ++i)
    11      {
    12        b = 2;
    13        b = 3;
    14        b = 4;
    15        b = 5;
    16        b = 6;
    17      }
    18    int *ap = malloc (sizeof(int));
    19    *ap = 1;
    20    printf ("%p\n", ap);
    21    *ap = 0;
    22    a = 0;
    23    return 0;
    24  }
...

Compiled with debug info:
...
$ gcc -g test.c
...

It takes a bit to execute:
...
$ time ./a.out
0x2252260

real    0m2.192s
user    0m2.188s
sys     0m0.001s
...

By disabling ASLR, we see that the malloc'ed pointer doesn't seem to change:
...
$ setarch $(uname -m) -R ./a.out
0x602260
$ setarch $(uname -m) -R ./a.out
0x602260
...

Now consider the following debug session:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b 20
Breakpoint 1 at 0x4005c5: file test.c, line 20.
(gdb) r
Starting program: a.out 

Breakpoint 1, main () at test.c:20
20        printf ("%p\n", ap);
(gdb) watch *(int *)0x602260 == 0
Hardware watchpoint 2: *(int *)0x602260 == 0
(gdb) c
Continuing.
0x602260

Hardware watchpoint 2: *(int *)0x602260 == 0

Old value = 0
New value = 1
main () at test.c:22
22        a = 0;
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004005c5 in main at test.c:20
        breakpoint already hit 1 time
2       hw watchpoint  keep y                      *(int *)0x602260 == 0
        breakpoint already hit 1 time
(gdb) 
...

So far, so good.  We set a watch point. It was reported as a hardware
watchpoint when we set it, and it's still a hardware watchpoint when it's
triggered.

Now we restart, and ... this takes a long time, so we press ^C to know what
happened:
...
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/vries/gdb_versions/devel/a.out 
^C
Program received signal SIGINT, Interrupt.
_dl_map_object_from_fd (name=name@entry=0x400379 "libc.so.6",
origname=origname@entry=0x0, fd=-1, fbp=fbp@entry=0x7fffffffd3e0,
realname=<optimized out>, loader=loader@entry=0x7ffff7ffe110, l_type=<optimized
out>, mode=<optimized out>, stack_endp=<optimized out>, nsid=<optimized out>)
at dl-load.c:1364
1364      if (__glibc_unlikely (GLRO(dl_profile) != NULL)
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000004005c5 in main at test.c:20
2       watchpoint     keep y                      *(int *)0x602260 == 0
...

The hw watchpoint silently degraded to a software watchpoint (due to being set
on unmapped memory).

It could be useful to warn in such a case, because a software watchpoint may be
much slower.

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

             reply	other threads:[~2021-02-15 14:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 14:03 vries at gcc dot gnu.org [this message]
2021-02-15 15:37 ` [Bug breakpoints/27422] " vries at gcc dot gnu.org
2024-01-07 14:53 ` ssbssa at sourceware dot org

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=bug-27422-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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).