RE: [PATCH] gdb fix for catch-syscall.exp

[Carl Love via Gdb-patches <gdb-patches@sourceware.org>]

Simon:

On Tue, 2021-11-23 at 15:34 -0500, Simon Marchi wrote:
> If you all agree that it's a bug, I would suggest reverting this
> patch
> and making a patch that kfails the test when on powerpc.  And
> ideally,
> someone should dig to understand why we don't see the return on
> powerpc
> (and fix it), but I'm not here to tell what other people should work
> on :).

OK, I think for powerpc the test should be a xfail.  Looking at the
README, kfail is for gdb known issues, xfail is for issues in the
environment including the OS.

I see xfail takes two arguments, the first one is the gdb bug number. 
So, I will need to file a bug before I finish this patch.

I am hoping someone has a suggestion on how to improve my patch to add
the xfail.  The issue is since Powerpc doesn't print the "Catchpoint 1
(returned from syscall execve)" but rather stops at main, the test
should not issue the continue command after the xfail.  In the case of
the xfail, I need to pass 0 backup so the if statement in proc
test_catch_syscall_execve can decide if the continue command should be
issued or not.  The change is a bit messy having to pass the return
value up.  Wondering if anyone has a better idea how to add the xfail?

Note, so far I have only tested this on Powerpc.  Patch is not ready
for committing.

                   Carl 


-------------------------------------------------
gdb Revert change to gdb.base/catch-syscall.exp

The previous commit:
   commit ab198279120fe7937c0970a8bb881922726678f9
   Author: Carl Love <cel@us.ibm.com>
   Date:   Wed Nov 17 22:29:33 2021 +0000

       gdb fix for catch-syscall.exp

Fixed the test failure on PowerPC but broke the test on amd64.  The issue is
both messages:

    Catchpoint 1 (call to syscall execve), ....
    Catchpoint 1 (returned from syscall execve),  ....

are seen on amd64 whereas on PowerPC only the "call to syscall execve" is
seen.  Based on the discussion on the mailing list, it is felt that this
is really an issue with the PowerPC kernel support not reporting both events.
Thus, the change is being reverted and will be marked as a kfail for Powerpc.
---
 gdb/testsuite/gdb.base/catch-syscall.exp | 38 +++++++++++++++++++-----
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
index 016d0a698a6..04fa2bf9687 100644
--- a/gdb/testsuite/gdb.base/catch-syscall.exp
+++ b/gdb/testsuite/gdb.base/catch-syscall.exp
@@ -127,7 +127,24 @@ proc check_return_from_syscall { syscall { pattern "" } } {
     }
 
     set thistest "syscall $syscall has returned"
-    gdb_test "continue" "Catchpoint $decimal \\(returned from syscall ${pattern}\\).*" $thistest
+    if { $pattern eq "execve" } {
+	gdb_test_multiple "continue" $thistest {
+	    -re -wrap "Catchpoint $decimal \\(returned from syscall ${pattern}\\).*" {
+		pass $thistest
+		return 1
+	    }
+	    -re -wrap ".*Breakpoint $decimal, main .*" {
+		# On Powerpc kernel does not report the returned from syscall
+		# as expected by the test.
+		xfail $thistest
+		return 0
+	    }
+	}
+
+    } else {
+	gdb_test "continue" "Catchpoint $decimal \\(returned from syscall ${pattern}\\).*" $thistest
+	return 1
+    }
 }
 
 # Internal procedure that performs two 'continue' commands and checks if
@@ -142,7 +159,11 @@ proc check_continue { syscall { pattern "" } } {
     # Testing if the inferior has called the syscall.
     check_call_to_syscall $syscall $pattern
     # And now, that the syscall has returned.
-    check_return_from_syscall $syscall $pattern
+    if [check_return_from_syscall $syscall $pattern] {
+	return 1
+    } else {
+	return 0
+    }
 }
 
 # Inserts a syscall catchpoint with an argument.
@@ -348,13 +369,14 @@ proc test_catch_syscall_execve {} {
 	# Check for entry/return across the execve, making sure that the
 	# syscall_state isn't lost when turning into a new process.
 	insert_catch_syscall_with_arg "execve"
+	if [check_continue "execve"] {
+	    # The check_continue test generates an XFAIL on Powerpc.  In
+	    # that case, gdb is already at main so don't do the continue.
 
-	# Check that the execve is called.
-	check_call_to_syscall "execve"
-
-	# Continue to main so extended-remote can read files as needed.
-	# (Otherwise that "Reading" output confuses gdb_continue_to_end.)
-	gdb_continue "main"
+	    # Continue to main so extended-remote can read files as needed.
+	    # (Otherwise that "Reading" output confuses gdb_continue_to_end.)
+	    gdb_continue "main"
+	}
 
 	# Now can we finish?
 	check_for_program_end
-- 
2.30.2