[Bug gdb/26078] New: arm-none-eabi-gdb ignores condition in data watchpoint

[Bug gdb/26078] New: arm-none-eabi-gdb ignores condition in data watchpoint

[maximilian.gerhardt at physec dot de]

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

            Bug ID: 26078
           Summary: arm-none-eabi-gdb ignores condition in data watchpoint
           Product: gdb
           Version: 8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: maximilian.gerhardt at physec dot de
  Target Milestone: ---

Cross-posting from
https://stackoverflow.com/questions/62172401/conditional-data-watchpoint-doesnt-work-in-arm-gdb
because I think GDB people might be able to help me here the most in the
bugtracker.

My intent is to be able to catch when a global variable has some exact value.
GDB has data
watchpoints(https://sourceware.org/gdb/current/onlinedocs/gdb/Set-Watchpoints.html)
according to which this can be implemented. 

Consider this simple program written for x86 Linux:


---------------------------------------
int myVar = 0;

void debug_watchpoints() {
        for(int i=0; i < 2000; i++) {
                myVar++;
        }
}

int main() {
        debug_watchpoints();
        return 0;
}
---------------------------------------

Compiling the program with 

gcc -o main -ggdb3 -Og main.c

And starting debugging with GDB: 

---------------------------------------
max@PC-LT-23:~/stackoverflow$ gdb ./main
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(gdb) b main 
Breakpoint 1 at 0x1146: file main.c, line 9.
(gdb) start
Temporary breakpoint 2 at 0x1146: file main.c, line 9.
Starting program: /home/max/stackoverflow/main 

Breakpoint 1, main () at main.c:9
9       int main() {
(gdb) watch myVar if myVar==1337
Hardware watchpoint 3: myVar
(gdb) continue
Continuing.

Hardware watchpoint 3: myVar

Old value = 1336
New value = 1337
debug_watchpoints () at main.c:4
4               for(int i=0; i < 2000; i++) {
(gdb) 
---------------------------------------

As you can see it halted the program at *exactly* the point in time when the
variable was set to 1337. 

Consider the **exact same program**, compiled with `arm-none-eabi-gcc` for a
STM32L476RG microcontroller which has a Cortex-M4F core. The used IDE here is
System Workbench for STM32 (aka Eclipse) with a project generated by
STM32CubeMX. 

Now launching `openocd` gives 

---------------------------------------
Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-04-12-08:33)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results
might differ compared to plain JTAG/SWD
padded zone erase set to 1
adapter speed: 8000 kHz
adapter_nsrst_delay: 100
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 8000 kHz
Info : STLINK v2.1 JTAG v34 API v2 M25 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.011074
Error: target voltage may be too low for reliable debugging
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : STM32L476RGTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08001340 msp: 0x20018000
---------------------------------------

A breakpoint is set in the `main` function and then the watchpoint is setup
exactly like before. Also, a breakpoint is is set after the execution of the
`debug_watchpoints()` function. 

---------------------------------------
GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) Reset_Handler () at ../startup/startup_stm32l476xx.s:63
63        ldr   sp, =_estack    /* Set stack pointer */

Temporary breakpoint 3, main () at ../Src/main.c:65
65      {

(gdb) watch myVar if myVar==1337
Hardware watchpoint 4: myVar
(gdb) info breakpoints
Num     Type           Disp Enb Address    What
2       breakpoint     keep y   0x08000f46 in main at ../Src/main.c:70
4       hw watchpoint  keep y              myVar
        stop only if myVar==1337
(gdb) 
---------------------------------------

When continuing the program, it now stops *at every modification of the
variable* with a `SIGTRAP`, regardless of whether the condition was met or not.

---------------------------------------
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54              for(int i=0; i < 2000; i++) {
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54              for(int i=0; i < 2000; i++) {
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54              for(int i=0; i < 2000; i++) {
(gdb) info breakpoint
Num     Type           Disp Enb Address    What
2       breakpoint     keep y   0x08000f46 in main at ../Src/main.c:70
4       hw watchpoint  keep y              myVar
        stop only if myVar==1337
(gdb) print myVar
$2 = 3
---------------------------------------

I can continue for as many times as I want, it just breaks each and every time
the variable is changed.

In my scenario of "debugging a memory corruption on the stack", I really need
GDB to evaluate the condition correctly, otherwise the program stops a thousand
times or more (every time a variable which happens to be at this memory
location is changed) and not at only the specific time a specific value is
written into it to catch a bug.

Why does `arm-none-eabi-gdb` differ here in its behavior from normal `gdb`?
Could the error lie in the Cortex-M4 hardware debugging capabilities,
`arm-none-eabi-gdb`, or `openocd` as the GDB server?

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

[Bug gdb/26078] arm-none-eabi-gdb ignores condition in data watchpoint

[maximilian.gerhardt at physec dot de]

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

Maximilian Gerhardt <maximilian.gerhardt at physec dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |x86_64-linux-gnu
             Target|                            |arm-none-eabi
              Build|                            |8.3.0.20190709-git

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