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