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

  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 31 bytes away from the beginning of the buffer
being modified, so that large memory accesses (if present) as well as
watching an unaligned memory address are exercised.

PR testsuite/31484
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484
---
 gdb/testsuite/gdb.base/memops-watchpoint.c   | 40 ++++++++++
 gdb/testsuite/gdb.base/memops-watchpoint.exp | 83 ++++++++++++++++++++
 2 files changed, 123 insertions(+)
 create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.c
 create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.exp

NB: Please let me know if you think there are more interesting tests
regarding watchpoint and memory accesses that can be done.  I tried to
make it cover the interesting scenarios but the testcase is small, so
maybe I'm not very creative.
  

On Sat, 20 Apr 2024 18:33:07 -0300
Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:

> diff --git a/gdb/testsuite/gdb.base/memops-watchpoint.exp b/gdb/testsuite/gdb.base/memops-watchpoint.exp
> new file mode 100644
> index 000000000000..6fc84eb469c4
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/memops-watchpoint.exp
> @@ -0,0 +1,83 @@
> +# 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.
> +
> +# It's not possible to check in which libc function the watchpoint triggers
> +# without its debug info.
> +require libc_has_debug_info

I'm wondering about the need for this requirement.  When I comment it
out and run it on a machine without libc debuginfo, I do see 3 FAILs,
but it seems to me that those could be turned into PASSes by changing
the regular expressions for the "continue until..." tests.

E.g. for the first one, with libc debuginfo, I see:

continue
Continuing.

Hardware watchpoint 2: -location a[31]

Old value = 101 'e'
New value = 0 '\000'
__memset_avx2_unaligned () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:146
146		VMOVU	%VMM(0), (%rdi)
(gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits

But, without libc debuginfo, the watchpoint still works:

continue
Continuing.

Hardware watchpoint 2: -location a[31]

Old value = 101 'e'
New value = 0 '\000'
0x00007ffff7e3553a in __memset_avx2_unaligned () from /lib64/libc.so.6
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits

As stated earlier, this could be turned into a PASS by tweaking the RE.

In both cases, we know that it's in a "memset" function.  (The presence
of minimal symbols provides GDB with this information.)

Kevin
  

Thank you for your review!

Kevin Buettner <kevinb@redhat.com> writes:

> On Sat, 20 Apr 2024 18:33:07 -0300
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
>
>> diff --git a/gdb/testsuite/gdb.base/memops-watchpoint.exp
>> b/gdb/testsuite/gdb.base/memops-watchpoint.exp
>> new file mode 100644
>> index 000000000000..6fc84eb469c4
>> --- /dev/null
>> +++ b/gdb/testsuite/gdb.base/memops-watchpoint.exp
>> @@ -0,0 +1,83 @@
>> +# 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.
>> +
>> +# It's not possible to check in which libc function the watchpoint triggers
>> +# without its debug info.
>> +require libc_has_debug_info
>
> I'm wondering about the need for this requirement.  When I comment it
> out and run it on a machine without libc debuginfo, I do see 3 FAILs,
> but it seems to me that those could be turned into PASSes by changing
> the regular expressions for the "continue until..." tests.
>
> E.g. for the first one, with libc debuginfo, I see:
>
> continue
> Continuing.
>
> Hardware watchpoint 2: -location a[31]
>
> Old value = 101 'e'
> New value = 0 '\000'
> __memset_avx2_unaligned () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:146
> 146		VMOVU	%VMM(0), (%rdi)
> (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>
> But, without libc debuginfo, the watchpoint still works:
>
> continue
> Continuing.
>
> Hardware watchpoint 2: -location a[31]
>
> Old value = 101 'e'
> New value = 0 '\000'
> 0x00007ffff7e3553a in __memset_avx2_unaligned () from /lib64/libc.so.6
> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>
> As stated earlier, this could be turned into a PASS by tweaking the RE.
>
> In both cases, we know that it's in a "memset" function.  (The presence
> of minimal symbols provides GDB with this information.)

I added the requirement because in my aarch64-linux system without libc6
debug info I get:

continue
Continuing.

Hardware watchpoint 2: -location a[28]

Old value = 104 'h'
New value = 0 '\000'
0x0000fffff7e90664 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits

And I just tested removing libc6-dbg from my x86_64-linux laptop:

continue
Continuing.

Hardware watchpoint 2: -location a[28]

Old value = 104 'h'
New value = 0 '\000'
0x00007ffff7d8e05f in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits

So it depends on the system.

One alternative would be to not use the require statement and run the
test until the watchpoint hits, and have a case in gdb_test_multiple to
mark as UNRESOLVED if the function name is '??'.

--
Thiago
  

On Sun, 21 Apr 2024 21:24:42 -0300
Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:

> >> +require libc_has_debug_info  
> >
> > I'm wondering about the need for this requirement.  When I comment it
> > out and run it on a machine without libc debuginfo, I do see 3 FAILs,
> > but it seems to me that those could be turned into PASSes by changing
> > the regular expressions for the "continue until..." tests.
[...]
> 
> I added the requirement because in my aarch64-linux system without libc6
> debug info I get:
> 
> continue
> Continuing.
> 
> Hardware watchpoint 2: -location a[28]
> 
> Old value = 104 'h'
> New value = 0 '\000'
> 0x0000fffff7e90664 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
> 
> And I just tested removing libc6-dbg from my x86_64-linux laptop:
> 
> continue
> Continuing.
> 
> Hardware watchpoint 2: -location a[28]
> 
> Old value = 104 'h'
> New value = 0 '\000'
> 0x00007ffff7d8e05f in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
> 
> So it depends on the system.

What distro are you using?

> One alternative would be to not use the require statement and run the
> test until the watchpoint hits, and have a case in gdb_test_multiple to
> mark as UNRESOLVED if the function name is '??'.

I'm in favor of this approach.

If we stick with the require statement, I think that Fedora testing
will frequently show this new test as unsupported since installing
debuginfo is less common / important that it used to be.  (This is
due to debuginfod doing it for you.  But I think that debuginfod is
mostly disabled when running the GDB tests.)
  

Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes:

> Kevin Buettner <kevinb@redhat.com> writes:
>
>> On Sat, 20 Apr 2024 18:33:07 -0300
>> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
>>
>>> +# It's not possible to check in which libc function the watchpoint triggers
>>> +# without its debug info.
>>> +require libc_has_debug_info
>>
>> I'm wondering about the need for this requirement.  When I comment it
>> out and run it on a machine without libc debuginfo, I do see 3 FAILs,
>> but it seems to me that those could be turned into PASSes by changing
>> the regular expressions for the "continue until..." tests.
>>
>> E.g. for the first one, with libc debuginfo, I see:
>>
>> continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location a[31]
>>
>> Old value = 101 'e'
>> New value = 0 '\000'
>> __memset_avx2_unaligned () at
>> ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:146
>> 146		VMOVU	%VMM(0), (%rdi)
>> (gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>>
>> But, without libc debuginfo, the watchpoint still works:
>>
>> continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location a[31]
>>
>> Old value = 101 'e'
>> New value = 0 '\000'
>> 0x00007ffff7e3553a in __memset_avx2_unaligned () from /lib64/libc.so.6
>> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>>
>> As stated earlier, this could be turned into a PASS by tweaking the RE.
>>
>> In both cases, we know that it's in a "memset" function.  (The presence
>> of minimal symbols provides GDB with this information.)
>
> I added the requirement because in my aarch64-linux system without libc6
> debug info I get:
>
> continue
> Continuing.
>
> Hardware watchpoint 2: -location a[28]
>
> Old value = 104 'h'
> New value = 0 '\000'
> 0x0000fffff7e90664 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits

<snip>

> So it depends on the system.
>
> One alternative would be to not use the require statement and run the
> test until the watchpoint hits, and have a case in gdb_test_multiple to
> mark as UNRESOLVED if the function name is '??'.

I was able to do this in v3. But I mark the test as UNSUPPORTED rather
than UNRESOLVED. The difference between them isn't always clear in my
mind, but I think UNSUPPORTED is better in this case.

--
Thiago
  

Kevin Buettner <kevinb@redhat.com> writes:

> On Sun, 21 Apr 2024 21:24:42 -0300
> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote:
>
>> >> +require libc_has_debug_info
>> >
>> > I'm wondering about the need for this requirement.  When I comment it
>> > out and run it on a machine without libc debuginfo, I do see 3 FAILs,
>> > but it seems to me that those could be turned into PASSes by changing
>> > the regular expressions for the "continue until..." tests.
> [...]
>>
>> I added the requirement because in my aarch64-linux system without libc6
>> debug info I get:
>>
>> continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location a[28]
>>
>> Old value = 104 'h'
>> New value = 0 '\000'
>> 0x0000fffff7e90664 in ?? () from /lib/aarch64-linux-gnu/libc.so.6
>> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>>
>> And I just tested removing libc6-dbg from my x86_64-linux laptop:
>>
>> continue
>> Continuing.
>>
>> Hardware watchpoint 2: -location a[28]
>>
>> Old value = 104 'h'
>> New value = 0 '\000'
>> 0x00007ffff7d8e05f in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> (gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
>>
>> So it depends on the system.
>
> What distro are you using?

Ubuntu. Version 22.04 on some machines, and version 23.10 on others.

>> One alternative would be to not use the require statement and run the
>> test until the watchpoint hits, and have a case in gdb_test_multiple to
>> mark as UNRESOLVED if the function name is '??'.
>
> I'm in favor of this approach.
>
> If we stick with the require statement, I think that Fedora testing
> will frequently show this new test as unsupported since installing
> debuginfo is less common / important that it used to be.  (This is
> due to debuginfod doing it for you.  But I think that debuginfod is
> mostly disabled when running the GDB tests.)

Yes, that is a good point. I think v3 should work with the output you
pasted in a previous email. Thank you for bring this up.

--
Thiago