public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org,  Luis Machado <luis.machado@arm.com>
Subject: Re: [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp
Date: Wed, 24 Apr 2024 14:05:31 -0300	[thread overview]
Message-ID: <87cyqe3d44.fsf@linaro.org> (raw)
In-Reply-To: <20240423105247.798dc561@f39-zbm-amd> (Kevin Buettner's message of "Tue, 23 Apr 2024 10:52:47 -0700")

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

-- 
Thiago

  reply	other threads:[~2024-04-24 17:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22 23:06 [PATCH v3 0/2] Add testcase for libc memory operations Thiago Jung Bauermann
2024-04-22 23:06 ` [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper Thiago Jung Bauermann
2024-04-23 17:09   ` Kevin Buettner
2024-04-24 16:25     ` Thiago Jung Bauermann
2024-04-25 19:39       ` Bernd Edlinger
2024-04-26  3:00         ` Thiago Jung Bauermann
2024-04-26  5:06           ` Bernd Edlinger
2024-04-26 16:35           ` Pedro Alves
2024-04-26 17:18             ` Thiago Jung Bauermann
2024-04-30  1:57               ` Thiago Jung Bauermann
2024-04-22 23:07 ` [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp Thiago Jung Bauermann
2024-04-23 17:52   ` Kevin Buettner
2024-04-24 17:05     ` Thiago Jung Bauermann [this message]
2024-04-24 23:22       ` Kevin Buettner
2024-04-26  1:42         ` Thiago Jung Bauermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cyqe3d44.fsf@linaro.org \
    --to=thiago.bauermann@linaro.org \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=luis.machado@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).