[Bug breakpoints/27422] New: Warn when degrading hw -> sw watchpoint
vries at gcc dot gnu.org
sourceware-bugzilla@sourceware.org
Mon Feb 15 14:03:57 GMT 2021
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.
More information about the Gdb-prs
mailing list