* [PATCH v3 0/2] Add testcase for libc memory operations @ 2024-04-22 23:06 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-22 23:07 ` [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp Thiago Jung Bauermann 0 siblings, 2 replies; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-22 23:06 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Luis Machado Hello, When I sent v2 yesterday, I hadn't seen. Kevin's review comments. This version addresses them. As a result, memops-watchpoint.exp now tries harder to work even if there's no libc debug info available. The new testcase doesn't use the libc_has_debug_info require helper anymore, so patch 1 is now an optional cleanup. For reference, v2 is here: https://inbox.sourceware.org/gdb-patches/20240421222657.1052635-1-thiago.bauermann@linaro.org/ and v1 is here: https://inbox.sourceware.org/gdb-patches/20240420213307.976401-1-thiago.bauermann@linaro.org/ Thiago Jung Bauermann (2): gdb/testsuite: Add libc_has_debug_info require helper gdb/testsuite: Add gdb.base/memops-watchpoint.exp gdb/testsuite/gdb.base/memops-watchpoint.c | 45 ++++++ gdb/testsuite/gdb.base/memops-watchpoint.exp | 160 +++++++++++++++++++ gdb/testsuite/gdb.base/relativedebug.exp | 13 +- gdb/testsuite/lib/gdb.exp | 56 +++++++ 4 files changed, 262 insertions(+), 12 deletions(-) create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.c create mode 100644 gdb/testsuite/gdb.base/memops-watchpoint.exp base-commit: fdaa4939e5024ea809c0d4d1aa6043a60b37d9b5 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-22 23:06 [PATCH v3 0/2] Add testcase for libc memory operations Thiago Jung Bauermann @ 2024-04-22 23:06 ` Thiago Jung Bauermann 2024-04-23 17:09 ` Kevin Buettner 2024-04-22 23:07 ` [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp Thiago Jung Bauermann 1 sibling, 1 reply; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-22 23:06 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Luis Machado Factor the test for libc debug info out of gdb.base/relativedebug.exp to a new procedure. Also, change the "info sharedlibrary" test to explicitly detect when libc has debug info. --- As mentioned in the cover letter, the new testcase doesn't use this helper procedure anymore so this is an optional patch. I think it's a nice cleanup, though I didn't find any other testcase that need it so perhaps the new helper is not as useful as I imagine it to be. I'm fine with not committing this patch. Changes in v3: - Include <stdio.h> in test program to avoid error when using clang (suggested by Kevin). gdb/testsuite/gdb.base/relativedebug.exp | 13 +----- gdb/testsuite/lib/gdb.exp | 56 ++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 12 deletions(-) diff --git a/gdb/testsuite/gdb.base/relativedebug.exp b/gdb/testsuite/gdb.base/relativedebug.exp index bf8d76887122..f882a5cf1676 100644 --- a/gdb/testsuite/gdb.base/relativedebug.exp +++ b/gdb/testsuite/gdb.base/relativedebug.exp @@ -13,7 +13,7 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. -require {!target_info exists gdb,nosignals} +require {!target_info exists gdb,nosignals} libc_has_debug_info standard_testfile .c @@ -28,17 +28,6 @@ clean_restart ${binfile} runto_main -set test "info sharedlibrary" -gdb_test_multiple $test $test { - -re ".*\(\\*\)\[^\r\n\]*/libc\.so.*$gdb_prompt $" { - # Skip the test below if libc doesn't have debug info. - unsupported "libc doesn't have debug info" - return -1 - } - -re ".*$gdb_prompt $" { - } -} - # pause () -> SIGALRM -> handler () -> abort () gdb_test "continue" "Program received signal SIGABRT.*" diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index cbd37fd30947..1e26937c0dcf 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -3699,6 +3699,62 @@ proc support_displaced_stepping {} { return 0 } +# Return 1 if GDB can find the libc debug info, or 0 and a reason string if it +# can't. This procedure is meant to be called by the require procedure. +gdb_caching_proc libc_has_debug_info {} { + global srcdir subdir gdb_prompt inferior_exited_re + + set me "libc_has_debug_info" + + # Compile a test program. + set src { + #include <stdio.h> + + int main (void) { + printf ("Hello, world!\n"); + return 0; + } + } + if {![gdb_simple_compile $me $src executable {debug}]} { + return [list 0 "failed to compile test program"] + } + + # No error message, compilation succeeded so now run it via gdb. + + gdb_exit + gdb_start + gdb_reinitialize_dir $srcdir/$subdir + gdb_load "$obj" + runto_main + set test "info sharedlibrary libc.so" + gdb_test_multiple $test $test { + -re ".*\(\\*\)\[^\r\n\]*/libc\.so.*$gdb_prompt $" { + # Matched the "(*)" in the "Syms Read" columns which means: + # "(*): Shared library is missing debugging information." + verbose -log "$me: libc doesn't have debug info" + set libc_has_debug_info 0 + set message "libc doesn't have debug info" + } + -re ".*Yes\[ \t\]+\[^\r\n\]*/libc\.so.*$gdb_prompt $" { + verbose -log "$me: libc has debug info" + set libc_has_debug_info 1 + } + default { + set libc_has_debug_info 0 + set message "libc not found in the inferior" + } + } + gdb_exit + remote_file build delete $obj + + verbose "$me: returning $libc_has_debug_info" 2 + if { $libc_has_debug_info } { + return $libc_has_debug_info + } else { + return [list $libc_has_debug_info $message] + } +} + # Run a test on the target to see if it supports vmx hardware. Return 1 if so, # 0 if it does not. Based on 'check_vmx_hw_available' from the GCC testsuite. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 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 0 siblings, 1 reply; 15+ messages in thread From: Kevin Buettner @ 2024-04-23 17:09 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: gdb-patches, Luis Machado On Mon, 22 Apr 2024 20:06:59 -0300 Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote: > Factor the test for libc debug info out of gdb.base/relativedebug.exp to > a new procedure. > > Also, change the "info sharedlibrary" test to explicitly detect when > libc has debug info. > --- > > As mentioned in the cover letter, the new testcase doesn't use this helper > procedure anymore so this is an optional patch. I think it's a nice > cleanup, though I didn't find any other testcase that need it so perhaps > the new helper is not as useful as I imagine it to be. I'm fine with not > committing this patch. > > Changes in v3: > - Include <stdio.h> in test program to avoid error when using clang > (suggested by Kevin). I agree that it's a nice cleanup and I think that it should go in. I've retested with CC_FOR_TARGET set to clang and also gcc. It works for both. Approved-by: Kevin Buettner <kevinb@redhat.com> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-23 17:09 ` Kevin Buettner @ 2024-04-24 16:25 ` Thiago Jung Bauermann 2024-04-25 19:39 ` Bernd Edlinger 0 siblings, 1 reply; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-24 16:25 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches, Luis Machado Hello Kevin, Kevin Buettner <kevinb@redhat.com> writes: > On Mon, 22 Apr 2024 20:06:59 -0300 > Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote: > >> Factor the test for libc debug info out of gdb.base/relativedebug.exp to >> a new procedure. >> >> Also, change the "info sharedlibrary" test to explicitly detect when >> libc has debug info. >> --- >> >> As mentioned in the cover letter, the new testcase doesn't use this helper >> procedure anymore so this is an optional patch. I think it's a nice >> cleanup, though I didn't find any other testcase that need it so perhaps >> the new helper is not as useful as I imagine it to be. I'm fine with not >> committing this patch. >> >> Changes in v3: >> - Include <stdio.h> in test program to avoid error when using clang >> (suggested by Kevin). > > I agree that it's a nice cleanup and I think that it should go in. > > I've retested with CC_FOR_TARGET set to clang and also gcc. It works > for both. > > Approved-by: Kevin Buettner <kevinb@redhat.com> Thank you! Pushed as commit f5ef12c3f1af. -- Thiago ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-24 16:25 ` Thiago Jung Bauermann @ 2024-04-25 19:39 ` Bernd Edlinger 2024-04-26 3:00 ` Thiago Jung Bauermann 0 siblings, 1 reply; 15+ messages in thread From: Bernd Edlinger @ 2024-04-25 19:39 UTC (permalink / raw) To: Thiago Jung Bauermann, gdb-patches Hi Thiago, On 4/24/24 18:25, Thiago Jung Bauermann wrote: > > Hello Kevin, > > Kevin Buettner <kevinb@redhat.com> writes: > >> On Mon, 22 Apr 2024 20:06:59 -0300 >> Thiago Jung Bauermann <thiago.bauermann@linaro.org> wrote: >> >>> Factor the test for libc debug info out of gdb.base/relativedebug.exp to >>> a new procedure. >>> >>> Also, change the "info sharedlibrary" test to explicitly detect when >>> libc has debug info. >>> --- >>> >>> As mentioned in the cover letter, the new testcase doesn't use this helper >>> procedure anymore so this is an optional patch. I think it's a nice >>> cleanup, though I didn't find any other testcase that need it so perhaps >>> the new helper is not as useful as I imagine it to be. I'm fine with not >>> committing this patch. >>> >>> Changes in v3: >>> - Include <stdio.h> in test program to avoid error when using clang >>> (suggested by Kevin). >> >> I agree that it's a nice cleanup and I think that it should go in. >> >> I've retested with CC_FOR_TARGET set to clang and also gcc. It works >> for both. >> >> Approved-by: Kevin Buettner <kevinb@redhat.com> > > Thank you! Pushed as commit f5ef12c3f1af. > I think I have an issue with this commmit. I use a self-built riscv-unknown-elf toolchain with newlib, so there is no libc at all, regardless of debug info. since today, I see messages like: Running /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp ... FAIL: gdb.base/relativedebug.exp: info sharedlibrary libc.so ERROR: tcl error sourcing /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp. ERROR: tcl error code TCL READ VARNAME ERROR: can't read "libc_has_debug_info": no such variable while executing "verbose "$me: returning $libc_has_debug_info" 2" (procedure "gdb_real__libc_has_debug_info" line 47) invoked from within "gdb_real__libc_has_debug_info" ("uplevel" body line 1) invoked from within "uplevel 2 [list $real_name {*}$args]" invoked from within "gdb_do_cache_wrap $real_name {*}$args" (procedure "gdb_do_cache" line 48) invoked from within "gdb_do_cache libc_has_debug_info" (procedure "libc_has_debug_info" line 1) invoked from within "libc_has_debug_info" ("uplevel" body line 1) invoked from within "uplevel 1 $fn" (procedure "require" line 11) invoked from within "require {!target_info exists gdb,nosignals} libc_has_debug_info" (file "/home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp" line 16) invoked from within "source /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp" invoked from within "catch "uplevel #0 source $test_file_name" msg" UNRESOLVED: gdb.base/relativedebug.exp: testcase '/home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp' aborted due to Tcl error PATH: gdb.base/relativedebug.exp: testcase '/home/ed/gnu/ while previously that looked like: gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main': /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): undefined reference to `alarm' /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): undefined reference to `pause' /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): undefined reference to `pause' collect2: error: ld returned 1 exit status UNTESTED: gdb.base/relativedebug.exp: failed to compile so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, but much easier to understand the output... Regards, Bernd. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 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 0 siblings, 2 replies; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-26 3:00 UTC (permalink / raw) To: Bernd Edlinger; +Cc: gdb-patches Hello Bernd, Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > Hi Thiago, > > On 4/24/24 18:25, Thiago Jung Bauermann wrote: >>> >> Thank you! Pushed as commit f5ef12c3f1af. > > I think I have an issue with this commmit. > I use a self-built riscv-unknown-elf toolchain with newlib, > so there is no libc at all, regardless of debug info. > since today, I see messages like: > Running /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp ... > FAIL: gdb.base/relativedebug.exp: info sharedlibrary libc.so > ERROR: tcl error sourcing /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp. > ERROR: tcl error code TCL READ VARNAME > ERROR: can't read "libc_has_debug_info": no such variable > while executing > "verbose "$me: returning $libc_has_debug_info" 2" > (procedure "gdb_real__libc_has_debug_info" line 47) > invoked from within > "gdb_real__libc_has_debug_info" <snip> Sorry for the trouble. I should have simulated a situation where GDB can't find libc.so in the inferior. I was able to reproduce the error above when I did. Could you please test the patch that I just sent? > while previously that looked like: > > gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main': > /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): undefined reference to `alarm' > /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: > /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): > undefined reference to `pause' > /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: > /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): > undefined reference to `pause' > collect2: error: ld returned 1 exit status > UNTESTED: gdb.base/relativedebug.exp: failed to compile > > so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, > but much easier to understand the output... On the plus side, with this problem fixed gdb.base/relativedebug.exp should exit early with: (gdb) info sharedlibrary libc.so No shared libraries matched. (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc not found in the inferior) Which will be even easier to understand the output. :-) -- Thiago ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-26 3:00 ` Thiago Jung Bauermann @ 2024-04-26 5:06 ` Bernd Edlinger 2024-04-26 16:35 ` Pedro Alves 1 sibling, 0 replies; 15+ messages in thread From: Bernd Edlinger @ 2024-04-26 5:06 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: gdb-patches Hello Thiago, On 4/26/24 05:00, Thiago Jung Bauermann wrote: > Sorry for the trouble. I should have simulated a situation where GDB > can't find libc.so in the inferior. I was able to reproduce the error > above when I did. > > Could you please test the patch that I just sent? > Yeah it works. Thanks a lot for the quick response. >> while previously that looked like: >> >> gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main': >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): undefined reference to `alarm' >> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): >> undefined reference to `pause' >> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): >> undefined reference to `pause' >> collect2: error: ld returned 1 exit status >> UNTESTED: gdb.base/relativedebug.exp: failed to compile >> >> so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, >> but much easier to understand the output... > > On the plus side, with this problem fixed gdb.base/relativedebug.exp > should exit early with: > > (gdb) info sharedlibrary libc.so > No shared libraries matched. > (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc not found in the inferior) > > Which will be even easier to understand the output. :-) > Yes, indeed. If I had one wish free, I would like to have these lines not mention the random /tmp/*.o file name: gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main': ... at least in the gdb.sum file. Thanks Bernd. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 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 1 sibling, 1 reply; 15+ messages in thread From: Pedro Alves @ 2024-04-26 16:35 UTC (permalink / raw) To: Thiago Jung Bauermann, Bernd Edlinger; +Cc: gdb-patches On 2024-04-26 04:00, Thiago Jung Bauermann wrote: > > Hello Bernd, > > Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > >> Hi Thiago, >> >> On 4/24/24 18:25, Thiago Jung Bauermann wrote: >>>> >>> Thank you! Pushed as commit f5ef12c3f1af. >> >> I think I have an issue with this commmit. >> I use a self-built riscv-unknown-elf toolchain with newlib, >> so there is no libc at all, regardless of debug info. >> since today, I see messages like: >> Running /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp ... >> FAIL: gdb.base/relativedebug.exp: info sharedlibrary libc.so >> ERROR: tcl error sourcing /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.exp. >> ERROR: tcl error code TCL READ VARNAME >> ERROR: can't read "libc_has_debug_info": no such variable >> while executing >> "verbose "$me: returning $libc_has_debug_info" 2" >> (procedure "gdb_real__libc_has_debug_info" line 47) >> invoked from within >> "gdb_real__libc_has_debug_info" > > <snip> > > Sorry for the trouble. I should have simulated a situation where GDB > can't find libc.so in the inferior. I was able to reproduce the error > above when I did. > > Could you please test the patch that I just sent? > >> while previously that looked like: >> >> gdb compile failed, /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: /tmp/ccjr19GC.o: in function `main': >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): undefined reference to `alarm' >> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): >> undefined reference to `pause' >> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): >> undefined reference to `pause' >> collect2: error: ld returned 1 exit status >> UNTESTED: gdb.base/relativedebug.exp: failed to compile >> >> so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, >> but much easier to understand the output... > > On the plus side, with this problem fixed gdb.base/relativedebug.exp > should exit early with: > > (gdb) info sharedlibrary libc.so > No shared libraries matched. > (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc not found in the inferior) > > Which will be even easier to understand the output. :-) > I don't think that's a good outcome, actually. It'll disable the testcase on systems that link with their libc statically (even if has debug info), or systems that name their libc something else. And I worry that the require predicate will start being used more with that particularity. The original check only returned early if a library called "*libc*" was found, and, it didn't have debug info. If those conditions didn't match, the testcase proceeded. That seems a lot safer. As in, only if we know for sure we have a libc without debug info, do we return early. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-26 16:35 ` Pedro Alves @ 2024-04-26 17:18 ` Thiago Jung Bauermann 2024-04-30 1:57 ` Thiago Jung Bauermann 0 siblings, 1 reply; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-26 17:18 UTC (permalink / raw) To: Pedro Alves; +Cc: Bernd Edlinger, gdb-patches Hello Pedro, Pedro Alves <pedro@palves.net> writes: > On 2024-04-26 04:00, Thiago Jung Bauermann wrote: >> >> Bernd Edlinger <bernd.edlinger@hotmail.de> writes: >> >>> while previously that looked like: >>> >>> gdb compile failed, >>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>> /tmp/ccjr19GC.o: in function `main': >>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): >>> undefined reference to `alarm' >>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): >>> undefined reference to `pause' >>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): >>> undefined reference to `pause' >>> collect2: error: ld returned 1 exit status >>> UNTESTED: gdb.base/relativedebug.exp: failed to compile >>> >>> so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, >>> but much easier to understand the output... >> >> On the plus side, with this problem fixed gdb.base/relativedebug.exp >> should exit early with: >> >> (gdb) info sharedlibrary libc.so >> No shared libraries matched. >> (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc >> not found in the inferior) >> >> Which will be even easier to understand the output. :-) >> > > I don't think that's a good outcome, actually. It'll disable the testcase on systems that > link > with their libc statically (even if has debug info), or systems that name their libc > something else. > And I worry that the require predicate will start being used more with that particularity. > > The original check only returned early if a library called "*libc*" was found, and, it > didn't > have debug info. If those conditions didn't match, the testcase proceeded. That seems a > lot safer. As in, only if we know for sure we have a libc without debug info, do we > return early. Ok, makes sense. I'll submit a patch for the libc_has_debug_info that makes it behave like the original check in gdb.base/relativedebug.exp did. -- Thiago ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper 2024-04-26 17:18 ` Thiago Jung Bauermann @ 2024-04-30 1:57 ` Thiago Jung Bauermann 0 siblings, 0 replies; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-30 1:57 UTC (permalink / raw) To: Pedro Alves; +Cc: Bernd Edlinger, gdb-patches Hello Pedro, Thiago Jung Bauermann <thiago.bauermann@linaro.org> writes: > Pedro Alves <pedro@palves.net> writes: > >> On 2024-04-26 04:00, Thiago Jung Bauermann wrote: >>> >>> Bernd Edlinger <bernd.edlinger@hotmail.de> writes: >>> >>>> while previously that looked like: >>>> >>>> gdb compile failed, >>>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>>> /tmp/ccjr19GC.o: in function `main': >>>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:30:(.text+0x28): >>>> undefined reference to `alarm' >>>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x30): >>>> undefined reference to `pause' >>>> /home/ed/gnu/riscv64-unknown-elf/lib/gcc/riscv64-unknown-elf/14.0.1/../../../../riscv64-unknown-elf/bin/ld: >>>> /home/ed/gnu/binutils-build-riscv64/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/relativedebug.c:31:(.text+0x38): >>>> undefined reference to `pause' >>>> collect2: error: ld returned 1 exit status >>>> UNTESTED: gdb.base/relativedebug.exp: failed to compile >>>> >>>> so not very noisy, newlib does apparently not have alarm, pause, sleep, and similar, >>>> but much easier to understand the output... >>> >>> On the plus side, with this problem fixed gdb.base/relativedebug.exp >>> should exit early with: >>> >>> (gdb) info sharedlibrary libc.so >>> No shared libraries matched. >>> (gdb) UNSUPPORTED: gdb.base/relativedebug.exp: require failed: libc_has_debug_info (libc >>> not found in the inferior) >>> >>> Which will be even easier to understand the output. :-) >>> >> >> I don't think that's a good outcome, actually. It'll disable the testcase on systems that >> link >> with their libc statically (even if has debug info), or systems that name their libc >> something else. >> And I worry that the require predicate will start being used more with that particularity. >> >> The original check only returned early if a library called "*libc*" was found, and, it >> didn't >> have debug info. If those conditions didn't match, the testcase proceeded. That seems a >> lot safer. As in, only if we know for sure we have a libc without debug info, do we >> return early. > > Ok, makes sense. I'll submit a patch for the libc_has_debug_info that > makes it behave like the original check in gdb.base/relativedebug.exp > did. Here it is: https://inbox.sourceware.org/gdb-patches/20240430015325.89780-1-thiago.bauermann@linaro.org/ -- Thiago ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp 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-22 23:07 ` Thiago Jung Bauermann 2024-04-23 17:52 ` Kevin Buettner 1 sibling, 1 reply; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-22 23:07 UTC (permalink / raw) To: gdb-patches; +Cc: Kevin Buettner, Luis Machado 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 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 + } + } +} ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp 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 0 siblings, 1 reply; 15+ messages in thread From: Kevin Buettner @ 2024-04-23 17:52 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: gdb-patches, Luis Machado 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp 2024-04-23 17:52 ` Kevin Buettner @ 2024-04-24 17:05 ` Thiago Jung Bauermann 2024-04-24 23:22 ` Kevin Buettner 0 siblings, 1 reply; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-24 17:05 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches, Luis Machado 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp 2024-04-24 17:05 ` Thiago Jung Bauermann @ 2024-04-24 23:22 ` Kevin Buettner 2024-04-26 1:42 ` Thiago Jung Bauermann 0 siblings, 1 reply; 15+ messages in thread From: Kevin Buettner @ 2024-04-24 23:22 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: gdb-patches, Luis Machado 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH v3 2/2] gdb/testsuite: Add gdb.base/memops-watchpoint.exp 2024-04-24 23:22 ` Kevin Buettner @ 2024-04-26 1:42 ` Thiago Jung Bauermann 0 siblings, 0 replies; 15+ messages in thread From: Thiago Jung Bauermann @ 2024-04-26 1:42 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb-patches, Luis Machado 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-04-30 1:57 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2024-04-24 23:22 ` Kevin Buettner 2024-04-26 1:42 ` Thiago Jung Bauermann
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).