[Bug tdep/29423] New: [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[Bug tdep/29423] New: [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

            Bug ID: 29423
           Summary: [gdb, tdep/aarch64] FAIL:
                    gdb.base/watchpoint-unaligned.exp: continue (timeout)
           Product: gdb
           Version: 12.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On aarch64 in OBS, I run into:
...
(gdb) watch data.u.size8twice[1]^M
Hardware watchpoint 241: data.u.size8twice[1]^M
(gdb) continue^M
Continuing.^M
FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
...

The timeout reproduces consistently on multiple configurations (distro version,
pie vs no-pie).

Not yet reproduced outside OBS.

On actual hardware the test-case passes consistently, and fast, under 3
seconds.  Even when forcefully switching back the last bit to software
watchpoints, the whole test still takes under 3 seconds.

AFAICT, this is the only watchpoint test that fails for me on aarch64.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14235
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14235&action=edit
debug patch

I'll try to add this to the package to get more information.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14236
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14236&action=edit
gdb.log (passing example)

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #3 from Luis Machado <luis.machado at arm dot com> ---
This is a known FAIL, due to imprecise hardware watchpoint triggers that vary
from hardware to hardware.

There was a fix in progress, but it turned out to be just a better heuristic
that wouldn't fix all the possible cases.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Luis Machado from comment #3)
> This is a known FAIL, due to imprecise hardware watchpoint triggers that
> vary from hardware to hardware.
> 
> There was a fix in progress, but it turned out to be just a better heuristic
> that wouldn't fix all the possible cases.

Ah, I see, that's
https://sourceware.org/pipermail/gdb-patches/2021-June/179452.html .

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #5 from Luis Machado <luis.machado at arm dot com> ---
Yes. It basically comes down to the fact we can't easily tell how many bytes
and what specific bytes were accessed when a hardware watchpoint triggers.

That are more complex cases where some SVE instructions can access scattered
bytes across a particular range.

In general hardware watchpoint triggers reported by GDB caused by instructions
accessing more than 8 bytes tend to be less reliable.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
FTR, I ran into this failure in OBS on a Cavium ThunderX2 CPU with:
...
CPU implementer : 0x43
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0x0af
CPU revision    : 1
...
which is mentioned here (
https://sourceware.org/pipermail/gdb-patches/2021-June/179463.html ) as having
the behaviour "report the trap address from the beginning of the memory range,
so that's less precise, but still valid according to the spec".

Didn't reproduce outside OBS on a jetson tx2 with:
...
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd07
CPU revision    : 2
...

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14239
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14239&action=edit
tentative patch

An attempt to address the hang in the generic part.

Can't test this outside of OBS, which makes developing the patch further
impractical.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14239|0                           |1
        is obsolete|                            |

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14240
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14240&action=edit
tentative patch

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #7)
> Created attachment 14239 [details]
> tentative patch
> 
> An attempt to address the hang in the generic part.
> 
> Can't test this outside of OBS, which makes developing the patch further
> impractical.

I've tested this patch in OBS, and unfortunately it didn't fix the fail in this
test-case, so I'm waiting to get my hands on a machine to reproduce this fail
and then investigate and test it.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[ahajkova at redhat dot com]

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

Alexandra Hájková <ahajkova at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahajkova at redhat dot com

--- Comment #10 from Alexandra Hájková <ahajkova at redhat dot com> ---
When running this test aarch64, Fedora 39:
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x3
CPU part        : 0xd0c
CPU revision    : 1

I'm getting TCL error:
root/build/gdb/gdb version  14.0.50.20230411-git -nw -nx -q -iex "set height 0"
-iex "set width 0" -data-directory /root/build/gdb/data-directory 

ERROR: -------------------------------------------
ERROR: in testcase
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR:  tcl error code TCL READ VARNAME
ERROR:  tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
    while executing
"list -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {     
}       -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alue = .*\r\n$gdb_prompt $" { 
..."
    ("uplevel" body line 1)
    invoked from within
"uplevel list $subst_code"
    (procedure "gdb_test_multiple" line 77)
    invoked from within
"gdb_test_multiple $test $test {
        -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {
        }
        -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alu..."
    ("foreach" body line 24)
    invoked from within
"foreach wpcount {4 7} {
    array set wpoffset_to_wpnum {}
    for {set wpoffset 1} {$wpoffset <= $wpcount} {incr wpoffset} {
        set test "$rwatch data...."
    (file
"/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
line 101)
    invoked from within
"source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name" msg"
--------------------------------------------------
                === gdb Summary ===

# of expected passes            142
# of unexpected failures        537
# of unresolved testcases       1
# of paths in test names        1
# of duplicate test names       16
/root/build/gdb/gdb version  14.0.50.20230411-git -nw -nx -q -iex "set height
0" -iex "set width 0" -data-directory /root/build/gdb/data-directory 

ERROR: -------------------------------------------
ERROR: in testcase
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR:  tcl error code TCL READ VARNAME
ERROR:  tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
    while executing
"list -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {     
}       -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alue = .*\r\n$gdb_prompt $" { 
..."
    ("uplevel" body line 1)
    invoked from within
"uplevel list $subst_code"
    (procedure "gdb_test_multiple" line 77)
    invoked from within
"gdb_test_multiple $test $test {
        -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {
        }
        -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alu..."
    ("foreach" body line 24)
    invoked from within
"foreach wpcount {4 7} {
    array set wpoffset_to_wpnum {}
    for {set wpoffset 1} {$wpoffset <= $wpcount} {incr wpoffset} {
        set test "$rwatch data...."
    (file
"/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
line 101)
    invoked from within
"source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name" msg"
--------------------------------------------------
make[2]: *** [Makefile:226: do-check-single] Error 1

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[ahajkova at redhat dot com]

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

--- Comment #11 from Alexandra Hájková <ahajkova at redhat dot com> ---
When running this test aarch64, Fedora 39:
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x3
CPU part        : 0xd0c
CPU revision    : 1

I'm getting TCL error:
root/build/gdb/gdb version  14.0.50.20230411-git -nw -nx -q -iex "set height 0"
-iex "set width 0" -data-directory /root/build/gdb/data-directory 

ERROR: -------------------------------------------
ERROR: in testcase
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR:  tcl error code TCL READ VARNAME
ERROR:  tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
    while executing
"list -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {     
}       -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alue = .*\r\n$gdb_prompt $" { 
..."
    ("uplevel" body line 1)
    invoked from within
"uplevel list $subst_code"
    (procedure "gdb_test_multiple" line 77)
    invoked from within
"gdb_test_multiple $test $test {
        -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {
        }
        -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alu..."
    ("foreach" body line 24)
    invoked from within
"foreach wpcount {4 7} {
    array set wpoffset_to_wpnum {}
    for {set wpoffset 1} {$wpoffset <= $wpcount} {incr wpoffset} {
        set test "$rwatch data...."
    (file
"/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
line 101)
    invoked from within
"source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name" msg"
--------------------------------------------------
                === gdb Summary ===

# of expected passes            142
# of unexpected failures        537
# of unresolved testcases       1
# of paths in test names        1
# of duplicate test names       16
/root/build/gdb/gdb version  14.0.50.20230411-git -nw -nx -q -iex "set height
0" -iex "set width 0" -data-directory /root/build/gdb/data-directory 

ERROR: -------------------------------------------
ERROR: in testcase
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp
ERROR:  can't read "wpoffset_to_wpnum(1)": no such element in array
ERROR:  tcl error code TCL READ VARNAME
ERROR:  tcl error info:
can't read "wpoffset_to_wpnum(1)": no such element in array
    while executing
"list -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {     
}       -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alue = .*\r\n$gdb_prompt $" { 
..."
    ("uplevel" body line 1)
    invoked from within
"uplevel list $subst_code"
    (procedure "gdb_test_multiple" line 77)
    invoked from within
"gdb_test_multiple $test $test {
        -re "\r\nCould not insert hardware watchpoint .*\r\n$gdb_prompt $" {
        }
        -re "$rwatch_exp $wpoffset_to_wpnum(1):.*alu..."
    ("foreach" body line 24)
    invoked from within
"foreach wpcount {4 7} {
    array set wpoffset_to_wpnum {}
    for {set wpoffset 1} {$wpoffset <= $wpcount} {incr wpoffset} {
        set test "$rwatch data...."
    (file
"/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
line 101)
    invoked from within
"source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source
/root/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/watchpoint-unaligned.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name" msg"
--------------------------------------------------
make[2]: *** [Makefile:226: do-check-single] Error 1

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #12 from Luis Machado <luis.machado at arm dot com> ---
What hardware were the fedora 39 issues seen on?

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[ahajkova at redhat dot com]

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

--- Comment #13 from Alexandra Hájková <ahajkova at redhat dot com> ---
(In reply to Luis Machado from comment #12)
> What hardware were the fedora 39 issues seen on?

It's Ampere Altra by Gigabyte

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago.bauermann at linaro dot org
             Status|NEW                         |WAITING

--- Comment #14 from Luis Machado <luis.machado at arm dot com> ---
Thanks. Could you please attach the gdb.log from that testcase run? That should
provide useful information on what is going on.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #15 from Luis Machado <luis.machado at arm dot com> ---
Please note these errors are a different situation compared to what this bug
was reported against (imprecise triggering of hardware watchpoints).

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #16 from Luis Machado <luis.machado at arm dot com> ---
I've cc-ed Thiago as he might have easier access to Altra-based hardware.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[ahajkova at redhat dot com]

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

--- Comment #17 from Alexandra Hájková <ahajkova at redhat dot com> ---
Created attachment 14814
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14814&action=edit
log

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

Luis Machado <luis.machado at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #18 from Luis Machado <luis.machado at arm dot com> ---
Thanks!

That gives me a good indication of what's going wrong.

Looks like these blocks in
gdb/nat/aarch64-linux-hw-point.c:aarch64_linux_get_debug_reg_capacity are
failing:

  if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0
      && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info)))

and

  if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0
      && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info)))

I suppose ptrace wouldn't fail, so I'm guessing compatible_debug_arch might be
the culprit, since it checks a hardcoded number of variations of
AARCH64_DEBUG_ARCH_V8*, and we may be returning false if the AARCH64_DEBUG_ARCH
is outside of the expected range.

We might need a new bug for this.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #19 from Luis Machado <luis.machado at arm dot com> ---
Just to make sure, it would be nice to confirm the ptrace requests aren't
coming back with a non-zero return value.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #20 from Tom Tromey <tromey at sourceware dot org> ---
I found another way to see watchpoint problems on aarch64.
Edit testsuite/gdb.ada/task_watch.exp and change the final
breakpoint to a plain continue:

diff --git a/gdb/testsuite/gdb.ada/task_watch.exp
b/gdb/testsuite/gdb.ada/task_watch.exp
index 0641008fb51..fedcf5073dc 100644
--- a/gdb/testsuite/gdb.ada/task_watch.exp
+++ b/gdb/testsuite/gdb.ada/task_watch.exp
@@ -80,6 +80,7 @@ gdb_test "info tasks" \
 # Now, resume the execution and make sure that GDB does not stop when
 # task 4 hits the watchpoint. Continuing thus results in our program
 # running to completion.
-set bp_location [gdb_get_line_number "STOP_HERE_2" ${testdir}/foo.adb]
-gdb_breakpoint foo.adb:$bp_location
-gdb_continue_to_breakpoint second ".*foo.adb:$bp_location.*null; --
STOP_HERE_2"
+# set bp_location [gdb_get_line_number "STOP_HERE_2" ${testdir}/foo.adb]
+# gdb_breakpoint foo.adb:$bp_location
+# gdb_continue_to_breakpoint second ".*foo.adb:$bp_location.*null; --
STOP_HERE_2"
+gdb_test "continue"


Now run the test.


I get:

continue
Continuing.
[Thread 0xfffff7e031d0 (LWP 104664) exited]
[Thread 0xfffff79f11d0 (LWP 104666) exited]
[Thread 0xfffff7bfa1d0 (LWP 104665) exited]
FAIL: gdb.ada/task_watch.exp: continue (timeout)


I think this is hitting the watchpoint but then getting confused.
I haven't really debugged any further.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[luis.machado at arm dot com]

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

--- Comment #21 from Luis Machado <luis.machado at arm dot com> ---
Yes, what you see with the modified ada test is likely a manifestation of the
original bug Tom De Vries reported.

There isn't a good fix for it yet, unless we start accepting false positives.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[ahajkova at redhat dot com]

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

--- Comment #22 from Alexandra Hájková <ahajkova at redhat dot com> ---
(In reply to Luis Machado from comment #18)
> Thanks!
> 
> That gives me a good indication of what's going wrong.
> 
> Looks like these blocks in
> gdb/nat/aarch64-linux-hw-point.c:aarch64_linux_get_debug_reg_capacity are
> failing:
> 
>   if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_WATCH, &iov) == 0
>       && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info)))
> 
> and
> 
>   if (ptrace (PTRACE_GETREGSET, tid, NT_ARM_HW_BREAK, &iov) == 0
>       && compatible_debug_arch (AARCH64_DEBUG_ARCH (dreg_state.dbg_info)))
> 
> I suppose ptrace wouldn't fail, so I'm guessing compatible_debug_arch might
> be the culprit, since it checks a hardcoded number of variations of
> AARCH64_DEBUG_ARCH_V8*, and we may be returning false if the
> AARCH64_DEBUG_ARCH is outside of the expected range.
> 
> We might need a new bug for this.

I've field a bug report and included the fix for the TCL error:
https://sourceware.org/bugzilla/show_bug.cgi?id=30340

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #23 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #4)
> (In reply to Luis Machado from comment #3)
> > This is a known FAIL, due to imprecise hardware watchpoint triggers that
> > vary from hardware to hardware.
> > 
> > There was a fix in progress, but it turned out to be just a better heuristic
> > that wouldn't fix all the possible cases.
> 
> Ah, I see, that's
> https://sourceware.org/pipermail/gdb-patches/2021-June/179452.html .

I've refreshed the patch and posted it as a v3.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #24 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2024-February/206706.html

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9a03f2185347bd8f20da9bf535bc68a8d0f18ce8

commit 9a03f2185347bd8f20da9bf535bc68a8d0f18ce8
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Mar 14 11:25:10 2024 +0100

    [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64

    On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run
into:
    ...
    (gdb) watch data.u.size8twice[1]^M
    Hardware watchpoint 241: data.u.size8twice[1]^M
    (gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1]
    continue^M
    Continuing.^M
    FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
    FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
    ...

    This happens as follows.

    We start the exec and set an 8-byte hardware watchpoint on
    data.u.size8twice[1] at address 0x440048:
    ...
    (gdb) p sizeof (data.u.size8twice[1])
    $1 = 8
    (gdb) p &data.u.size8twice[1]
    $2 = (uint64_t *) 0x440048 <data+16>
    ...

    We continue execution, and a 16-byte write at address 0x440040 triggers the
    hardware watchpoint:
    ...
      4101c8:       a9000801        stp     x1, x2, [x0]
    ...

    When checking whether a watchpoint has triggered in
    aarch64_stopped_data_address, we check against address 0x440040 (passed in
    parameter addr_trap).  This behaviour is documented:
    ...
              /* ADDR_TRAP reports the first address of the memory range
                 accessed by the CPU, regardless of what was the memory
                 range watched.  ...  */
    ...
    and consequently the matching logic compares against an addr_watch_aligned:
    ...
              && addr_trap >= addr_watch_aligned
              && addr_trap < addr_watch + len)
    ...

    However, the comparison fails:
    ...
    (gdb) p /x addr_watch_aligned
    $3 = 0x440048
    (gdb) p addr_trap >= addr_watch_aligned
    $4 = false
    ...

    Consequently, aarch64_stopped_data_address returns false, and
    stopped_by_watchpoint returns false, and watchpoints_triggered returns 0,
    which make infrun think it's looking at a delayed hardware
    breakpoint/watchpoint trap:
    ...
      [infrun] handle_signal_stop: stop_pc=0x4101c8
      [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap,
ignoring
    ...
    Infrun then ignores the trap and continues, but runs into the same
situation
    again and again, causing a hang which then causes the test timeout.

    Fix this by allowing a match 8 bytes below addr_watch_aligned.  This
    introduces the possibility for false positives, so we only do this for
regular
    "value changed" watchpoints.

    An earlier version of this patch worked by aligning addr_watch_aligned to
16
    instead of 8:
    ...
    -  const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i],
8);
    +  const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i],
16);
    ...
    but while that fixed the test-case, it didn't fix the problem completely,
so
    extend the test-case to check more scenarios.

    Tested on aarch64-linux.

    Tested-By: Luis Machado <luis.machado@arm.com>
    Approved-By: Luis Machado <luis.machado@arm.com>

    PR tdep/29423
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |15.1

--- Comment #26 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0ee25f97d21e7d57b9fdb0dd0690638bb3d17361

commit 0ee25f97d21e7d57b9fdb0dd0690638bb3d17361
Author: Tom Tromey <tromey@adacore.com>
Date:   Fri Apr 19 07:54:19 2024 -0600

    Fix regression on aarch64-linux gdbserver

    Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64")
    fixed a watchpoint bug in gdb -- but did not touch the corresponding
    code in gdbserver.

    This patch moves the gdb code into gdb/nat, so that it can be shared
    with gdbserver, and then changes gdbserver to use it, fixing the bug.

    This is yet another case where having a single back end would prevent
    bugs.

    I tested this using the AdaCore internal gdb testsuite.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
    Approved-By: Luis Machado <luis.machado@arm.com>

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

[Bug tdep/29423] [gdb, tdep/aarch64] FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #28 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6f9909c4179983330a29b6fd246b39ab1b003934

commit 6f9909c4179983330a29b6fd246b39ab1b003934
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Aug 12 16:35:05 2025 +0200

    [gdb/tdep] Handle M1 ldp in aarch64_stopped_data_address

    In test-case gdb.base/watchpoint-unaligned.exp, in function
write_size8twice,
    two adjacent 8-byte vars are written.  For aarch64, we use a single stp
    instruction for that.

    If we do the same in function read_size8twice for two adjacent 8-byte var
reads
    using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
    ...
    (gdb) continue^M
    Continuing.^M
    FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
    FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
    ...

    The same problem was observed for stp in PR tdep/29423, fixed by commit
    9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on
aarch64").

    See that commit for an explanation of the hang.

    That commit introduced max_access_size in aarch64_stopped_data_address:
    ...
               The access size also can be larger than that of the watchpoint
               itself.  For instance, the access size of an stp instruction is
16.
               So, if we use stp to store to address p, and set a watchpoint on
               address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
               RK3399 SOC). But it also can be p (observed on M1 SOC). 
Checking
               for this situation introduces the possibility of false
positives,
               so we only do this for hw_write watchpoints.  */
            const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
    ...

    If we say that hangs are worse than false positives, then we should also
fix
    this case.

    Fix this by setting max_access_size to 16 for all watchpoint types.

    Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.

    Approved-By: Luis Machado <luis.machado.foss@gmail.com>

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