[PATCH v3] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp

[PATCH v3] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp

[Tiezhu Yang]

If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the test case
gdb.base/attach-pie-noexec.exp without superuser, the gdb.log shows the
following info:

  (gdb) attach 6500
  Attaching to process 6500
  ptrace: Operation not permitted.
  (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach

It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.

It is better to make can_spawn_for_attach to return false for this case.
It would have to setup a small test program, compile it to exec, spawn it
and try to attach to it.

With this patch, we can see "please check privileges and try again" in
the log info, and then we can do the following processes to test:
(1) set ptrace_scope as 0
    $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
    $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
    $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
 gdb/testsuite/lib/gdb.exp | 37 ++++++++++++++++++++++++++++++-------
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 60f7b83571a..8af2c011a3e 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5055,7 +5055,10 @@ proc gdb_exit { } {
 # Return true if we can spawn a program on the target and attach to
 # it.
 
-proc can_spawn_for_attach { } {
+gdb_caching_proc can_spawn_for_attach {
+    global gdb_prompt
+    set test "can spawn for attach"
+
     # We use exp_pid to get the inferior's pid, assuming that gives
     # back the pid of the program.  On remote boards, that would give
     # us instead the PID of e.g., the ssh client, etc.
@@ -5070,6 +5073,32 @@ proc can_spawn_for_attach { } {
 	return 0
     }
 
+    set me "can_spawn_for_attach"
+    set src { int main() { sleep (600); return 0; } }
+    if {![gdb_simple_compile $me $src executable]} {
+        return 0
+    }
+
+    set test_spawn_id [spawn_wait_for_attach $obj]
+    set test_pid [spawn_id_get_pid $test_spawn_id]
+
+    gdb_start
+    file delete $obj
+    gdb_test_multiple "attach $test_pid" $test {
+        -re "Attaching to process $test_pid\r\n.*No executable file now.*\r\n$gdb_prompt $" {
+          pass $test
+          kill_wait_spawned_process $test_spawn_id
+          return 1
+        }
+        -re "Attaching to process $test_pid\r\n.*ptrace: Operation not permitted\\.\r\n$gdb_prompt $" {
+          unsupported "$test (please check privileges and try again)"
+          kill_wait_spawned_process $test_spawn_id
+          return 0
+        }
+    }
+
+    kill_wait_spawned_process $test_spawn_id
+
     # Assume yes.
     return 1
 }
@@ -5119,12 +5148,6 @@ proc spawn_id_get_pid { spawn_id } {
 proc spawn_wait_for_attach { executable_list } {
     set spawn_id_list {}
 
-    if ![can_spawn_for_attach] {
-	# The caller should have checked can_spawn_for_attach itself
-	# before getting here.
-	error "can't spawn for attach with this target/board"
-    }
-
     foreach {executable} $executable_list {
 	# Note we use Expect's spawn, not Tcl's exec, because with
 	# spawn we control when to wait for/reap the process.  That
-- 
2.27.0

Re: [PATCH v3] gdb: testsuite: fix wrong expected result in attach-pie-noexec.exp

[Simon Marchi]

> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 60f7b83571a..8af2c011a3e 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -5055,7 +5055,10 @@ proc gdb_exit { } {
>  # Return true if we can spawn a program on the target and attach to
>  # it.
>  
> -proc can_spawn_for_attach { } {
> +gdb_caching_proc can_spawn_for_attach {
> +    global gdb_prompt

Instead of declaring gdb_prompt global, just use $::gdb_prompt where
necessary.

> +    set test "can spawn for attach"

You don't need this, see below.

> +
>      # We use exp_pid to get the inferior's pid, assuming that gives
>      # back the pid of the program.  On remote boards, that would give
>      # us instead the PID of e.g., the ssh client, etc.
> @@ -5070,6 +5073,32 @@ proc can_spawn_for_attach { } {
>  	return 0
>      }
>  
> +    set me "can_spawn_for_attach"
> +    set src { int main() { sleep (600); return 0; } }

Space between `main` and `()`.  Put `void` in the parenthesis too.

> +    if {![gdb_simple_compile $me $src executable]} {
> +        return 0
> +    }
> +
> +    set test_spawn_id [spawn_wait_for_attach $obj]

Given that we are in the function to check whether it is possible for
the target board to spawn for attach, I'm a little worried that on some
boards that can't spawn a process on the target (using remote_spawn),
this will error out in a non clean way.  But I don't really have an idea
of how to test this in practice, so I'm fine with it, and we can always
adjust it later if needed.

I'm thinking that we could add (if needed, not right now) some board
properties that say whether the target board supports attaching.  Values
could be "yes", "no" and "probe", where "probe" would try attaching.

Most boards that can't spawn for attach will likely have use_gdb_stub
set anyway, so they will have returned before reaching this.

> +    set test_pid [spawn_id_get_pid $test_spawn_id]
> +
> +    gdb_start
> +    file delete $obj
> +    gdb_test_multiple "attach $test_pid" $test {

Replace $test with "can spawn for attach".

I wasn't sure about this, whether this would work for remote targets
(GDB running locally, GDBserver running on a different system).  For
attach to work, then gdb_start would likely automatically connect GDB to
GDBserver, just like the native-extended-gdbserver board does.  So the
attach here would do the right thing, attach through the remote target,
not the native GDB target.  So it sounds ok.

Anyway, we current have a

    if [is_remote target] then {
	return 0
    }

at the beginning of can_spawn_for_attach, so it would have returned
already.  There would be some more work needed to support this use case.

If debugging remotely but using the (non-extended) remote protocol, then
it would probably work similar to the native-gdbserver board, where
gdb_start does not connect GDB to GDBserver.  So the attach would use
the native target, which is not what we want.  But again, the is_remote
target check shown above would have returned 0 already, so we are good
for now.  We can cross that bridge when we get there, if we ever want to
support that use case.


> +        -re "Attaching to process $test_pid\r\n.*No executable file now.*\r\n$gdb_prompt $" {
> +          pass $test

Instead of $test here, use $gdb_test_name.  It's a magic variable that
will hold the test's name.

Instead of ending with "\r\n$gdb_prompt $", you can use -wrap:

  -re -wrap "..." {
    ...
  }

> +          kill_wait_spawned_process $test_spawn_id
> +          return 1
> +        }
> +        -re "Attaching to process $test_pid\r\n.*ptrace: Operation not permitted\\.\r\n$gdb_prompt $" {
> +          unsupported "$test (please check privileges and try again)"

Hmm we want the test name to describe what happened.  Maybe say
"operation not permitted" in the parenthesis.

> +          kill_wait_spawned_process $test_spawn_id
> +          return 0
> +        }
> +    }

Please test your patch with

  RUNTESTFLAGS="--target_board=native-gdbserver"
  RUNTESTFLAGS="--target_board=native-extended-gdbserver"

You will likely find that you need to handle other messages.

Simon