diff mbox series

[gdb/testsuite] Fix can_spawn_for_attach_1 consistency check

Message ID 20240517095341.6035-1-tdevries@suse.de
State Committed
Headers
Series [gdb/testsuite] Fix can_spawn_for_attach_1 consistency check |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Tom de Vries May 17, 2024, 9:53 a.m. UTC 
  When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
target board native-gdbserver, we run into:
...
(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
ERROR: gdbserver does not support attach 4827 without extended-remote
    while executing
"error "gdbserver does not support $command without extended-remote""
    (procedure "gdb_test_multiple" line 51)
    invoked from within
"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
        -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
            # Not permitte..."
    (procedure "gdb_real__can_spawn_for_attach_1" line 27)
    invoked from within
"gdb_real__can_spawn_for_attach_1"
...

The problem is that:
- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
  designed to be called only from that function, and
- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
  test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
  can_spawn_for_attach_1 directly.

Fix this by copying the early-outs from can_spawn_for_attach to
can_spawn_for_attach_1.

Tested on x86_64-linux.

Reported-By: Simon Marchi <simark@simark.ca>
---
 gdb/testsuite/lib/gdb.exp | 7 +++++++
 1 file changed, 7 insertions(+)


base-commit: 44fc9616c2e74396395f60c9a601317e4c4c4733

Comments

Alexandra Petlanova Hajkova May 20, 2024, 1:47 p.m. UTC | #1 
>
>  gdb_caching_proc can_spawn_for_attach_1 {} {
> +    # For the benefit of gdb-caching-proc-consistency.exp, which
> +    # calls can_spawn_for_attach_1 directly.  Keep in sync with
> +    # can_spawn_for_attach.
> +    if { [is_remote target] || [target_info exists use_gdb_stub] } {
> +       return 0
> +    }
> +
>      # Assume yes.
>      set res 1
>
>
> This solution looks reasonable to me. Also I've tried running this test on
aarch64 but it always passes there:

 make check RUNTESTFLAGS="--target_board=native-gdbserver"
TESTS=gdb.testsuite/gdb-caching-proc-consistency.exp

 Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Tom de Vries May 20, 2024, 2:42 p.m. UTC | #2 
On 5/20/24 15:47, Alexandra Petlanova Hajkova wrote:
>   Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com 

Hi Alexandra,

thanks for the review, pushed.

Thanks,
- Tom
diff mbox series

Patch

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index aea0ba599c7..55f6ab1fd8b 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -6191,6 +6191,13 @@  proc gdb_exit { } {
 # return 0 only if we cannot attach because it's unsupported.
 
 gdb_caching_proc can_spawn_for_attach_1 {} {
+    # For the benefit of gdb-caching-proc-consistency.exp, which
+    # calls can_spawn_for_attach_1 directly.  Keep in sync with
+    # can_spawn_for_attach.
+    if { [is_remote target] || [target_info exists use_gdb_stub] } {
+	return 0
+    }
+
     # Assume yes.
     set res 1