diff mbox series

[v3,2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp

Message ID 20240422230700.1173173-3-thiago.bauermann@linaro.org
State New
Headers
Series Add testcase for libc memory operations |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Thiago Jung Bauermann April 22, 2024, 11:07 p.m. UTC 
  Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove.
These functions are frequently optimized with specialized instructions
that favor larger memory access operations, so make sure GDB behaves
correctly in their presence.

There's a separate watched variable for each function so that the testcase
can test whether GDB correctly identified the watchpoint that triggered.

Also, the watchpoint is 28 bytes away from the beginning of the buffer
being modified, so that large memory accesses (if present) are exercised.

PR testsuite/31484
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484
---

Changes in v3:
- Reworked "continue until memset/memcpy/memmove watchpoint hits" tests to
  have a chance to work even without libc debug info (Suggested by Kevin).
- Dropped "require libc6_has_debug_info" call (Suggested by Kevin).

Changes in v2:
- Ensure watchpoints are aligned to 4 bytes.
- Add kfail for arm-linux.


 gdb/testsuite/gdb.base/memops-watchpoint.c   |  45 ++++++
 gdb/testsuite/gdb.base/memops-watchpoint.exp | 160 +++++++++++++++++++
 2 files changed, 205 insertions(+)
 create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.c
 create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.exp

Comments

Kevin Buettner April 23, 2024, 5:52 p.m. UTC | #1 
On Mon, 22 Apr 2024 20:07:00 -0300
Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:

> +set saw_watch_trigger 0
> +set saw_function 0
> +set is_supported 1
> +set message "continue until memcpy watchpoint hits"
> +set watch_trigger \
> +	[multi_line \
> +	     "Continuing\\." \
> +	     "" \
> +	     "(Hardware w|W)atchpoint ${decimal}: -location b\\\[28\\\]" \
> +	     "" \
> +	     "Old value = 101 'e'" \
> +	     "New value = 114 'r'"]
> +gdb_test_multiple "continue" $message {
> +    -re $watch_trigger {
> +	set saw_watch_trigger 1
> +	exp_continue
> +    }
> +    -re ".*memcpy.* \\(\\) at .*:$decimal\r\n" {
> +	set saw_function 1
> +	exp_continue
> +    }
> +    -re ".*memcpy.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
> +	set saw_function 1
> +	exp_continue
> +    }
> +    -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
> +	set is_supported 0
> +	unsupported "symbol for memcpy not found"
> +	exp_continue
> +    }
> +    -re "$gdb_prompt $" {
> +	if { $is_supported } {
> +	    setup_kfail breakpoints/31665 arm*-*-linux*
> +	    gdb_assert { $saw_watch_trigger && $saw_function } $message
> +	}
> +    }
> +}

For this test, on Fedora 39 x86_64 without glibc debuginfo, I see:

    continue
    Continuing.

    Hardware watchpoint 3: -location b[28]

    Old value = 101 'e'
    New value = 114 'r'
    0x00007ffff7e34b19 in __memmove_avx_unaligned () from /lib64/libc.so.6
    (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits


When I run it on Fedora 39 x86_64 w/ glibc debuginfo, I see the expected PASS:

    continue
    Continuing.

    Hardware watchpoint 3: -location b[28]

    Old value = 101 'e'
    New value = 114 'r'
    __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:226
    226		VMOVU	%VMM(1), -VEC_SIZE(%rdi,%rdx)
    (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits

I think you can fix the FAIL for the no-glibc-debuginfo case by
tweaking the RE in the same way that you did for the memmove test.

I also have Fedora 39 (Asahi Remix) running on an M1 macbook.  When
I try this test on that machine, I see some timeouts...

    (gdb) watch -location a[28]
    Hardware watchpoint 2: -location a[28]
    (gdb) PASS: gdb.base/memops-watchpoint.exp: set watch on a
    watch -location b[28]
    Hardware watchpoint 3: -location b[28]
    (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on b
    watch -location c[28]
    Hardware watchpoint 4: -location c[28]
    (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on c
    continue
    Continuing.

    Hardware watchpoint 2: -location a[28]

    Old value = 104 'h'
    New value = 0 '\000'
    __GI___memset_generic () at ../sysdeps/aarch64/memset.S:67
    67		tbz	count, 5, 1f
    (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
    continue
    Continuing.
    FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits (timeout)
    continue
    FAIL: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits (timeout)
    testcase /ironwood1/sourceware-git/macbook-review/bld/../../worktree-review/gdb/testsuite/gdb.base/memops-watchpoint.exp completed in 20 seconds

		    === gdb Summary ===

    # of expected passes		4
    # of unexpected failures	2

Is this demonstrating the bug (31484) ?

Kevin
Thiago Jung Bauermann April 24, 2024, 5:05 p.m. UTC | #2 
Kevin Buettner <kevinb@redhat.com> writes:

> On Mon, 22 Apr 2024 20:07:00 -0300
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
>
>> +set saw_watch_trigger 0
>> +set saw_function 0
>> +set is_supported 1
>> +set message "continue until memcpy watchpoint hits"
>> +set watch_trigger \
>> +	[multi_line \
>> +	     "Continuing\\." \
>> +	     "" \
>> +	     "(Hardware w|W)atchpoint ${decimal}: -location b\\\[28\\\]" \
>> +	     "" \
>> +	     "Old value = 101 'e'" \
>> +	     "New value = 114 'r'"]
>> +gdb_test_multiple "continue" $message {
>> +    -re $watch_trigger {
>> +	set saw_watch_trigger 1
>> +	exp_continue
>> +    }
>> +    -re ".*memcpy.* \\(\\) at .*:$decimal\r\n" {
>> +	set saw_function 1
>> +	exp_continue
>> +    }
>> +    -re ".*memcpy.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
>> +	set saw_function 1
>> +	exp_continue
>> +    }
>> +    -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
>> +	set is_supported 0
>> +	unsupported "symbol for memcpy not found"
>> +	exp_continue
>> +    }
>> +    -re "$gdb_prompt $" {
>> +	if { $is_supported } {
>> +	    setup_kfail breakpoints/31665 arm*-*-linux*
>> +	    gdb_assert { $saw_watch_trigger && $saw_function } $message
>> +	}
>> +    }
>> +}
>
> For this test, on Fedora 39 x86_64 without glibc debuginfo, I see:
>
>     continue
>     Continuing.
>
>     Hardware watchpoint 3: -location b[28]
>
>     Old value = 101 'e'
>     New value = 114 'r'
>     0x00007ffff7e34b19 in __memmove_avx_unaligned () from /lib64/libc.so.6
>     (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits
>
>
> When I run it on Fedora 39 x86_64 w/ glibc debuginfo, I see the expected PASS:
>
>     continue
>     Continuing.
>
>     Hardware watchpoint 3: -location b[28]
>
>     Old value = 101 'e'
>     New value = 114 'r'
>     __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:226
>     226		VMOVU	%VMM(1), -VEC_SIZE(%rdi,%rdx)
>     (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits
>
> I think you can fix the FAIL for the no-glibc-debuginfo case by
> tweaking the RE in the same way that you did for the memmove test.

That's true. Thanks! I'll make the change for v4.

> I also have Fedora 39 (Asahi Remix) running on an M1 macbook.  When
> I try this test on that machine, I see some timeouts...
>
>     (gdb) watch -location a[28]
>     Hardware watchpoint 2: -location a[28]
>     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watch on a
>     watch -location b[28]
>     Hardware watchpoint 3: -location b[28]
>     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on b
>     watch -location c[28]
>     Hardware watchpoint 4: -location c[28]
>     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on c
>     continue
>     Continuing.
>
>     Hardware watchpoint 2: -location a[28]
>
>     Old value = 104 'h'
>     New value = 0 '\000'
>     __GI___memset_generic () at ../sysdeps/aarch64/memset.S:67
>     67		tbz	count, 5, 1f
>     (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>     continue
>     Continuing.
>     FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits (timeout)
>     continue
>     FAIL: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits (timeout)
>     testcase /ironwood1/sourceware-git/macbook-review/bld/../../worktree-review/gdb/testsuite/gdb.base/memops-watchpoint.exp completed in 20 seconds
>
> 		    === gdb Summary ===
>
>     # of expected passes		4
>     # of unexpected failures	2
>
> Is this demonstrating the bug (31484) ?

Hm. Probably. I haven't seen this behaviour in my tests. It's hard to
say why GDB hung. Can you try to "set debug infrun on" at that point?

diff --git a/gdb/testsuite/gdb.base/memops-watchpoint.exp b/gdb/testsuite/gdb.base/memops-watchpoint.exp
index 4005b1eecf85..5920608453a4 100644
--- a/gdb/testsuite/gdb.base/memops-watchpoint.exp
+++ b/gdb/testsuite/gdb.base/memops-watchpoint.exp
@@ -82,6 +82,8 @@ gdb_test_multiple "continue" $message {
     }
 }
 
+gdb_test_no_output "set debug infrun on"
+
 set saw_watch_trigger 0
 set saw_function 0
 set is_supported 1
Kevin Buettner April 24, 2024, 11:22 p.m. UTC | #3 
On Wed, 24 Apr 2024 14:05:31 -0300
Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:

> > I also have Fedora 39 (Asahi Remix) running on an M1 macbook.  When
> > I try this test on that machine, I see some timeouts...
> >
> >     (gdb) watch -location a[28]
> >     Hardware watchpoint 2: -location a[28]
> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watch on a
> >     watch -location b[28]
> >     Hardware watchpoint 3: -location b[28]
> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on b
> >     watch -location c[28]
> >     Hardware watchpoint 4: -location c[28]
> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on c
> >     continue
> >     Continuing.
> >
> >     Hardware watchpoint 2: -location a[28]
> >
> >     Old value = 104 'h'
> >     New value = 0 '\000'
> >     __GI___memset_generic () at ../sysdeps/aarch64/memset.S:67
> >     67		tbz	count, 5, 1f
> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
> >     continue
> >     Continuing.
> >     FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits (timeout)
> >     continue
> >     FAIL: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits (timeout)
> >     testcase /ironwood1/sourceware-git/macbook-review/bld/../../worktree-review/gdb/testsuite/gdb.base/memops-watchpoint.exp completed in 20 seconds
> >
> > 		    === gdb Summary ===
> >
> >     # of expected passes		4
> >     # of unexpected failures	2
> >
> > Is this demonstrating the bug (31484) ?  
> 
> Hm. Probably. I haven't seen this behaviour in my tests. It's hard to
> say why GDB hung. Can you try to "set debug infrun on" at that point?

I tried running the test again on my macbook and can no longer
reproduce that failure.  I'm seeing 6 passes now.  (No reboots or
updates either. uptime shows that it's been up for 111 days.)

Kevin
Thiago Jung Bauermann April 26, 2024, 1:42 a.m. UTC | #4 
Kevin Buettner <kevinb@redhat.com> writes:

> On Wed, 24 Apr 2024 14:05:31 -0300
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
>
>> > I also have Fedora 39 (Asahi Remix) running on an M1 macbook.  When
>> > I try this test on that machine, I see some timeouts...
>> >
>> >     (gdb) watch -location a[28]
>> >     Hardware watchpoint 2: -location a[28]
>> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watch on a
>> >     watch -location b[28]
>> >     Hardware watchpoint 3: -location b[28]
>> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on b
>> >     watch -location c[28]
>> >     Hardware watchpoint 4: -location c[28]
>> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: set watchpoint on c
>> >     continue
>> >     Continuing.
>> >
>> >     Hardware watchpoint 2: -location a[28]
>> >
>> >     Old value = 104 'h'
>> >     New value = 0 '\000'
>> >     __GI___memset_generic () at ../sysdeps/aarch64/memset.S:67
>> >     67		tbz	count, 5, 1f
>> >     (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>> >     continue
>> >     Continuing.
>> >     FAIL: gdb.base/memops-watchpoint.exp: continue until memcpy watchpoint hits (timeout)
>> >     continue
>> >     FAIL: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits (timeout)
>> >     testcase /ironwood1/sourceware-git/macbook-review/bld/../../worktree-review/gdb/testsuite/gdb.base/memops-watchpoint.exp completed in 20 seconds
>> >
>> > 		    === gdb Summary ===
>> >
>> >     # of expected passes		4
>> >     # of unexpected failures	2
>> >
>> > Is this demonstrating the bug (31484) ?  
>> 
>> Hm. Probably. I haven't seen this behaviour in my tests. It's hard to
>> say why GDB hung. Can you try to "set debug infrun on" at that point?
>
> I tried running the test again on my macbook and can no longer
> reproduce that failure.  I'm seeing 6 passes now.  (No reboots or
> updates either. uptime shows that it's been up for 111 days.)

Ah, interesting. I think it's unlikely to be an issue related to this
testcase then. I expect problems with watchpoints triggering with
memset/memcpy/memmove to be deterministic. E.g., the kernel doesn't
report a close enough data address because the hand-optimized memcpy
used some very specialized instruction with a very wide data access
range, and thus GDB doesn't recognize why the SIGTRAP happened.

As an example, this test did uncover a problem in arm-linux-gnueabihf,
and it manifested as the watchpoints triggering when the inferior
program is exiting:

continue
Continuing.
b = 'This is a relatively long string...'
c = 'This is a relatively long string...'

Hardware watchpoint 2: -location a[28]

Old value = 104 'h'
New value = 128 '\200'
0xf7fc27de in _dl_fini () at dl-fini.c:51
warning: 51	dl-fini.c: No such file or directory
(gdb) KFAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits (PRMS: breakpoints/31665)
diff mbox series

Patch

diff --git a/gdb/testsuite/gdb.base/memops-watchpoint.c b/gdb/testsuite/gdb.base/memops-watchpoint.c
new file mode 100644
index 000000000000..0255cfb43404
--- /dev/null
+++ b/gdb/testsuite/gdb.base/memops-watchpoint.c
@@ -0,0 +1,45 @@ 
+/* This test program is part of GDB, the GNU debugger.
+
+   Copyright 2024 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <stdio.h>
+#include <string.h>
+
+int
+main (void)
+{
+  /* Some targets need 4-byte alignment for hardware watchpoints.  */
+  char s[40] __attribute__ ((aligned (4)))
+    = "This is a relatively long string...";
+  char a[40] __attribute__ ((aligned (4)))
+    = "String to be overwritten with zeroes";
+  char b[40] __attribute__ ((aligned (4)))
+    = "Another string to be memcopied...";
+  char c[40] __attribute__ ((aligned (4)))
+    = "Another string to be memmoved...";
+
+  /* Break here.  */
+  memset (a, 0, sizeof (a));
+
+  memcpy (b, s, sizeof (b));
+
+  memmove (c, s, sizeof (c));
+
+  printf ("b = '%s'\n", b);
+  printf ("c = '%s'\n", c);
+
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.base/memops-watchpoint.exp b/gdb/testsuite/gdb.base/memops-watchpoint.exp
new file mode 100644
index 000000000000..4005b1eecf85
--- /dev/null
+++ b/gdb/testsuite/gdb.base/memops-watchpoint.exp
@@ -0,0 +1,160 @@ 
+# Copyright 2024 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test a binary that uses standard libc memory operation functions.  They are
+# frequently optimized with specialized instructions, so make sure GDB behaves
+# correctly in their presence.
+
+standard_testfile
+set options "-fno-builtin-memset -fno-builtin-memcpy -fno-builtin-memmove"
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
+	  [list debug additional_flags=$options]] } {
+    return -1
+}
+
+set linespec ${srcfile}:[gdb_get_line_number "Break here"]
+if ![runto ${linespec}] {
+    return -1
+}
+
+gdb_test "watch -location a\[28\]" \
+    "(Hardware w|W)atchpoint ${decimal}: -location a\\\[28\\\]" \
+    "set watch on a"
+gdb_test "watch -location b\[28\]" \
+    "(Hardware w|W)atchpoint ${decimal}: -location b\\\[28\\\]" \
+    "set watchpoint on b"
+gdb_test "watch -location c\[28\]" \
+    "(Hardware w|W)atchpoint ${decimal}: -location c\\\[28\\\]" \
+    "set watchpoint on c"
+
+# For the tests below, split the pattern matching in two parts: one for the
+# watchpoint trigger, and another for the line showing the function name.
+# This is to allow the tests to work if there's a properly named symbol for
+# the function, even if there's no libc debug info.
+
+set saw_watch_trigger 0
+set saw_function 0
+set is_supported 1
+set message "continue until memset watchpoint hits"
+set watch_trigger \
+	[multi_line \
+	     "Continuing\\." \
+	     "" \
+	     "(Hardware w|W)atchpoint ${decimal}: -location a\\\[28\\\]" \
+	     "" \
+	     "Old value = 104 'h'" \
+	     "New value = 0 '\\\\000'"]
+gdb_test_multiple "continue" $message {
+    -re $watch_trigger {
+	set saw_watch_trigger 1
+	exp_continue
+    }
+    -re ".*memset.* \\(\\) at .*:$decimal\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re ".*memset.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set is_supported 0
+	unsupported "symbol for memset not found"
+	exp_continue
+    }
+    -re "$gdb_prompt $" {
+	if { $is_supported } {
+	    setup_kfail breakpoints/31665 arm*-*-linux*
+	    gdb_assert { $saw_watch_trigger && $saw_function } $message
+	}
+    }
+}
+
+set saw_watch_trigger 0
+set saw_function 0
+set is_supported 1
+set message "continue until memcpy watchpoint hits"
+set watch_trigger \
+	[multi_line \
+	     "Continuing\\." \
+	     "" \
+	     "(Hardware w|W)atchpoint ${decimal}: -location b\\\[28\\\]" \
+	     "" \
+	     "Old value = 101 'e'" \
+	     "New value = 114 'r'"]
+gdb_test_multiple "continue" $message {
+    -re $watch_trigger {
+	set saw_watch_trigger 1
+	exp_continue
+    }
+    -re ".*memcpy.* \\(\\) at .*:$decimal\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re ".*memcpy.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set is_supported 0
+	unsupported "symbol for memcpy not found"
+	exp_continue
+    }
+    -re "$gdb_prompt $" {
+	if { $is_supported } {
+	    setup_kfail breakpoints/31665 arm*-*-linux*
+	    gdb_assert { $saw_watch_trigger && $saw_function } $message
+	}
+    }
+}
+
+# Note: Some architectures use memcpy for memmove.
+set saw_watch_trigger 0
+set saw_function 0
+set is_supported 1
+set message "continue until memmove watchpoint hits"
+set watch_trigger \
+	[multi_line \
+	     "Continuing\\." \
+	     "" \
+	     "(Hardware w|W)atchpoint ${decimal}: -location c\\\[28\\\]" \
+	     "" \
+	     "Old value = 100 'd'" \
+	     "New value = 114 'r'"]
+gdb_test_multiple "continue" $message {
+    -re $watch_trigger {
+	set saw_watch_trigger 1
+	exp_continue
+    }
+    -re ".*(memmove|memcpy).* \\(\\) at .*:$decimal\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re ".*(memmove|memcpy).* \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set saw_function 1
+	exp_continue
+    }
+    -re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
+	set is_supported 0
+	unsupported "symbol for memmove not found"
+	exp_continue
+    }
+    -re "$gdb_prompt $" {
+	if { $is_supported } {
+	    setup_kfail breakpoints/31665 arm*-*-linux*
+	    gdb_assert { $saw_watch_trigger && $saw_function } $message
+	}
+    }
+}