[PATCH v3 0/2] Add testcase for libc memory operations

[PATCH v3 0/2] Add testcase for libc memory operations

[Thiago Jung Bauermann]

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

[PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Thiago Jung Bauermann]

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.
 

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

[Thiago Jung Bauermann]

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
+	}
+    }
+}

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Kevin Buettner]

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>

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

[Kevin Buettner]

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

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Thiago Jung Bauermann]

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

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

[Thiago Jung Bauermann]

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

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

[Kevin Buettner]

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

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Bernd Edlinger]

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.

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

[Thiago Jung Bauermann]

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

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Thiago Jung Bauermann]

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

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Bernd Edlinger]

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.

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Pedro Alves]

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.

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Thiago Jung Bauermann]

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

Re: [PATCH v3 1/2] gdb/testsuite: Add libc_has_debug_info require helper

[Thiago Jung Bauermann]

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