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

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

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)

-- 
Thiago