[PATCH] gdb fix for catch-syscall.exp

[PATCH] gdb fix for catch-syscall.exp

[Carl Love]

GDB maintainers:

The following patch fixes three test failures and an expect error.  The
expect error ERROR: can't read "arch1": no such variable is the result
of the if/else statement in proc test_catch_syscall_multi_arch not
matching the power platform.  The power platform, starting with Power
8, has "le" in the platform string to indicate a Little Endian system. 
The current expect string doesn't match the "le" in the name.

The other three failures are the result of the execve instruction that
starts executing the new program.  The expect script is looking for the
return from the execve command which doesn't occur since execve
replaces the current process image.

The patch was tested on a Power 10 LE system with no regressions.

Please let me know if the patch is acceptable for mainline.  Thanks.

                       Carl 


-------------------------------------------------------------------
gdb fix for catch-syscall.exp

Remove check_continue "execve" from Proc test_catch_syscall_execve.

The check_continue proceedure checs that the command, execve, starts and
checks for the return from the command.  The execve command starts a new
program and thus the return from the command causing the test to fail.

The call to proc check_continue "execve" is removed and replaced with
just the call to check_call_to_syscall "execve" to verify the command
executed.  The next test in proc test_catch_syscall_execve verifies that
the new program started and hit the break point in main.

Update the check for the PowerPC architecture.  Power Little Endian systems
include "le" in the name.  The istarget "power64-*-linux*" check fails to
match LE sytems.  The expected string is updated to capture both Big Endian
and Little Endian systems.  Power 10 LE istarget prints as:
powerpc64le-unknown-linux-gnu.

This patch fixes three failures and the error:

    ERROR: can't read "arch1": no such variable

Patch tested on Power 10 ppc64le GNU/Linux platform.
---
 gdb/testsuite/gdb.base/catch-syscall.exp | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
index 811a92b0aea..8b496712df5 100644
--- a/gdb/testsuite/gdb.base/catch-syscall.exp
+++ b/gdb/testsuite/gdb.base/catch-syscall.exp
@@ -348,7 +348,9 @@ 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"
-	check_continue "execve"
+
+	# 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.)
@@ -550,7 +552,7 @@ proc test_catch_syscall_multi_arch {} {
 	set syscall2_name "write"
 	set syscall_number 1
     } elseif { [istarget "powerpc-*-linux*"] \
-		   || [istarget "powerpc64-*-linux*"] } {
+		   || [istarget "powerpc64*-linux*"] } {
 	set arch1 "powerpc:common"
 	set arch2 "powerpc:common64"
 	set syscall1_name "openat"
-- 
2.30.2

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

[Tom Tromey]

>>>>> "Carl" == Carl Love via Gdb-patches <gdb-patches@sourceware.org> writes:

Carl> +	# check that the execve is called
Carl> +	check_call_to_syscall "execve"

In gdb, normally a comment should start with a capital letter and end
with a ".".  This patch is ok with this tweak.  Thank you.

Tom

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

[Simon Marchi]

On 2021-11-17 6:30 p.m., Carl Love via Gdb-patches wrote:
> GDB maintainers:
> 
> The following patch fixes three test failures and an expect error.  The
> expect error ERROR: can't read "arch1": no such variable is the result
> of the if/else statement in proc test_catch_syscall_multi_arch not
> matching the power platform.  The power platform, starting with Power
> 8, has "le" in the platform string to indicate a Little Endian system. 
> The current expect string doesn't match the "le" in the name.
> 
> The other three failures are the result of the execve instruction that
> starts executing the new program.  The expect script is looking for the
> return from the execve command which doesn't occur since execve
> replaces the current process image.
> 
> The patch was tested on a Power 10 LE system with no regressions.
> 
> Please let me know if the patch is acceptable for mainline.  Thanks.
> 
>                        Carl 
> 
> 
> -------------------------------------------------------------------
> gdb fix for catch-syscall.exp
> 
> Remove check_continue "execve" from Proc test_catch_syscall_execve.
> 
> The check_continue proceedure checs that the command, execve, starts and
> checks for the return from the command.  The execve command starts a new
> program and thus the return from the command causing the test to fail.
> 
> The call to proc check_continue "execve" is removed and replaced with
> just the call to check_call_to_syscall "execve" to verify the command
> executed.  The next test in proc test_catch_syscall_execve verifies that
> the new program started and hit the break point in main.
> 
> Update the check for the PowerPC architecture.  Power Little Endian systems
> include "le" in the name.  The istarget "power64-*-linux*" check fails to
> match LE sytems.  The expected string is updated to capture both Big Endian
> and Little Endian systems.  Power 10 LE istarget prints as:
> powerpc64le-unknown-linux-gnu.
> 
> This patch fixes three failures and the error:
> 
>     ERROR: can't read "arch1": no such variable
> 
> Patch tested on Power 10 ppc64le GNU/Linux platform.
> ---
>  gdb/testsuite/gdb.base/catch-syscall.exp | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
> index 811a92b0aea..8b496712df5 100644
> --- a/gdb/testsuite/gdb.base/catch-syscall.exp
> +++ b/gdb/testsuite/gdb.base/catch-syscall.exp
> @@ -348,7 +348,9 @@ 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"
> -	check_continue "execve"
> +
> +	# 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.)
> @@ -550,7 +552,7 @@ proc test_catch_syscall_multi_arch {} {
>  	set syscall2_name "write"
>  	set syscall_number 1
>      } elseif { [istarget "powerpc-*-linux*"] \
> -		   || [istarget "powerpc64-*-linux*"] } {
> +		   || [istarget "powerpc64*-linux*"] } {
>  	set arch1 "powerpc:common"
>  	set arch2 "powerpc:common64"
>  	set syscall1_name "openat"
> -- 
> 2.30.2
> 
> 

Hi Carl,

This patch causes this failure regression on Ubuntu 20.04, amd64:

FAIL: gdb.base/catch-syscall.exp: execve: continue to main

From gdb.log:

 615 continue^M
 616 Continuing.^M
 617 process 2022222 is executing new program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/catch-syscall/catch-syscall^M
 618 ^M
 619 Catchpoint 18 (returned from syscall execve), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
 620 (gdb) FAIL: gdb.base/catch-syscall.exp: execve: continue to main

Simon

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

[Carl Love]

Simon:

On Thu, 2021-11-18 at 13:10 -0500, Simon Marchi wrote:
> 
> Hi Carl,
> 
> This patch causes this failure regression on Ubuntu 20.04, amd64:
> 
> FAIL: gdb.base/catch-syscall.exp: execve: continue to main
> 
> From gdb.log:
> 
>  615 continue^M
>  616 Continuing.^M
>  617 process 2022222 is executing new program:
> /home/smarchi/build/binutils-
> gdb/gdb/testsuite/outputs/gdb.base/catch-syscall/catch-syscall^M
>  618 ^M
>  619 Catchpoint 18 (returned from syscall execve), 0x00007ffff7fd0100
> in _start () from /lib64/ld-linux-x86-64.so.2^M
>  620 (gdb) FAIL: gdb.base/catch-syscall.exp: execve: continue to main
> 

Interesting.  I understood that the execve call would not return to the
caller except in the case of an error.  Not sure why it behaves
differently on amd64 versus Power and Intel?  Let me take a look and
see if I can create a fix with a test multiple to cover both cases.

Thanks for letting me know.

                   Carl 

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

[Simon Marchi]

On 2021-11-19 19:27, Carl Love wrote:
> Simon:
> 
> On Thu, 2021-11-18 at 13:10 -0500, Simon Marchi wrote:
>>
>> Hi Carl,
>>
>> This patch causes this failure regression on Ubuntu 20.04, amd64:
>>
>> FAIL: gdb.base/catch-syscall.exp: execve: continue to main
>>
>> From gdb.log:
>>
>>  615 continue^M
>>  616 Continuing.^M
>>  617 process 2022222 is executing new program:
>> /home/smarchi/build/binutils-
>> gdb/gdb/testsuite/outputs/gdb.base/catch-syscall/catch-syscall^M
>>  618 ^M
>>  619 Catchpoint 18 (returned from syscall execve), 0x00007ffff7fd0100
>> in _start () from /lib64/ld-linux-x86-64.so.2^M
>>  620 (gdb) FAIL: gdb.base/catch-syscall.exp: execve: continue to main
>>
> 
> Interesting.  I understood that the execve call would not return to the
> caller except in the case of an error.  Not sure why it behaves
> differently on amd64 versus Power and Intel?  Let me take a look and
> see if I can create a fix with a test multiple to cover both cases.
> 
> Thanks for letting me know.
> 
>                    Carl 
> 

Did you manage to reproduce, or do you need more data from me?

Simon

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

[John Baldwin]

On 11/19/21 4:27 PM, Carl Love via Gdb-patches wrote:
> Simon:
> 
> On Thu, 2021-11-18 at 13:10 -0500, Simon Marchi wrote:
>>
>> Hi Carl,
>>
>> This patch causes this failure regression on Ubuntu 20.04, amd64:
>>
>> FAIL: gdb.base/catch-syscall.exp: execve: continue to main
>>
>>  From gdb.log:
>>
>>   615 continue^M
>>   616 Continuing.^M
>>   617 process 2022222 is executing new program:
>> /home/smarchi/build/binutils-
>> gdb/gdb/testsuite/outputs/gdb.base/catch-syscall/catch-syscall^M
>>   618 ^M
>>   619 Catchpoint 18 (returned from syscall execve), 0x00007ffff7fd0100
>> in _start () from /lib64/ld-linux-x86-64.so.2^M
>>   620 (gdb) FAIL: gdb.base/catch-syscall.exp: execve: continue to main
>>
> 
> Interesting.  I understood that the execve call would not return to the
> caller except in the case of an error.  Not sure why it behaves
> differently on amd64 versus Power and Intel?  Let me take a look and
> see if I can create a fix with a test multiple to cover both cases.
> 
> Thanks for letting me know.

Note that the thread/process that calls execve() does still "return"
from the kernel, it just returns to the entry point of the executable
with the contents of the user address space wiped.  I'm not quite sure
how Linux treats this, but on FreeBSD at least this "return" is treated
as a successful return from the execve system call.  In fact, I think
Linux on at least amd64 reports two events: one for an "execve" event and
one for the system call return event judging by a commit made in FreeBSD
to emulate ptrace() for Linux binaries:

https://cgit.freebsd.org/src/commit/?id=6e66030c4c05331f9b0adf87c31f2f233dd3ae1f

-- 
John Baldwin

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

[Carl Love]

Simon:

On Sun, 2021-11-21 at 20:07 -0500, Simon Marchi wrote:
>          Carl 
> > 
> 
> Did you manage to reproduce, or do you need more data from me?
> 
I can't reproduce what you saw.  But I am hoping to put together a
patch today that will use the multiple test to look for the response as
seen on amd64 but also handle not seeing the response as seen on Power.
The plan will be then for you and I to test the patch to make sure it
works on both.  Thanks.

           Carl 

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

[Simon Marchi]

> Note that the thread/process that calls execve() does still "return"
> from the kernel, it just returns to the entry point of the executable
> with the contents of the user address space wiped.  I'm not quite sure
> how Linux treats this, but on FreeBSD at least this "return" is treated
> as a successful return from the execve system call.  In fact, I think
> Linux on at least amd64 reports two events: one for an "execve" event and
> one for the system call return event judging by a commit made in FreeBSD
> to emulate ptrace() for Linux binaries:
>
> https://cgit.freebsd.org/src/commit/?id=6e66030c4c05331f9b0adf87c31f2f233dd3ae1f

Yes, that's what I see on Linux too.  With an x86-64 binary:


    $ ./gdb -q --data-directory=data-directory m64
    Reading symbols from m64...
    (gdb) catch syscall execve
    Catchpoint 1 (syscall 'execve' [59])
    (gdb) r
    Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/m64

    Catchpoint 1 (call to syscall execve), 0x00007ffff7ea92fb in execve () at ../sysdeps/unix/syscall-template.S:78
    78      ../sysdeps/unix/syscall-template.S: No such file or directory.
    (gdb) c
    Continuing.
    process 3592054 is executing new program: /home/smarchi/build/binutils-gdb-all-targets/gdb/m64

    Catchpoint 1 (returned from syscall execve), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2

and an x86 binary (on an actual x86 kernel, not on top of an x86-64
kernel):


    $ ./gdb -q -nx --data-directory=data-directory ./a.out
    Reading symbols from ./a.out...
    (gdb) catch syscall execve
    Catchpoint 1 (syscall 'execve' [11])
    (gdb) r
    Starting program: /home/simark/build/binutils-gdb/gdb/a.out

    Catchpoint 1 (call to syscall execve), 0xb7fddcb0 in __kernel_vsyscall ()
    (gdb) c
    Continuing.
    process 3734 is executing new program: /home/simark/build/binutils-gdb/gdb/a.out

    Catchpoint 1 (returned from syscall execve), 0xb7fdec60 in ?? () from /lib/ld-linux.so.2

In both cases, we see the execve syscall return at the entry point of
the dynamic linker/loader.  I tested on aarch64 too, same thing.

I indeed see that on powerpc we don't get the return:

    $ ./gdb -q -nx --data-directory=data-directory ./a.out
    Reading symbols from ./a.out...
    (gdb) catch syscall execve
    Catchpoint 1 (syscall 'execve' [11])
    (gdb) r
    Starting program: /home/simark/build/binutils-gdb/gdb/a.out

    Catchpoint 1 (call to syscall execve), 0x00007ffff7e6f18c in execve () from /lib64/libc.so.6
    (gdb) c
    Continuing.
    process 98693 is executing new program: /home/simark/build/binutils-gdb/gdb/a.out

    Catchpoint 1 (call to syscall execve), 0x00007ffff7e6f18c in execve () from /lib64/libc.so.6

The behavior on powerpc sounds like a bug to me, and adjusting the test
like this patch did just covers it up.  It doesn't make sense for that
behavior to be different per arch, for the same OS.

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
:).

Simon

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

[John Baldwin]

On 11/23/21 12:34 PM, Simon Marchi wrote:
>> Note that the thread/process that calls execve() does still "return"
>> from the kernel, it just returns to the entry point of the executable
>> with the contents of the user address space wiped.  I'm not quite sure
>> how Linux treats this, but on FreeBSD at least this "return" is treated
>> as a successful return from the execve system call.  In fact, I think
>> Linux on at least amd64 reports two events: one for an "execve" event and
>> one for the system call return event judging by a commit made in FreeBSD
>> to emulate ptrace() for Linux binaries:
>>
>> https://cgit.freebsd.org/src/commit/?id=6e66030c4c05331f9b0adf87c31f2f233dd3ae1f
> 
> Yes, that's what I see on Linux too.  With an x86-64 binary:
> 
> 
>      $ ./gdb -q --data-directory=data-directory m64
>      Reading symbols from m64...
>      (gdb) catch syscall execve
>      Catchpoint 1 (syscall 'execve' [59])
>      (gdb) r
>      Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/m64
> 
>      Catchpoint 1 (call to syscall execve), 0x00007ffff7ea92fb in execve () at ../sysdeps/unix/syscall-template.S:78
>      78      ../sysdeps/unix/syscall-template.S: No such file or directory.
>      (gdb) c
>      Continuing.
>      process 3592054 is executing new program: /home/smarchi/build/binutils-gdb-all-targets/gdb/m64
> 
>      Catchpoint 1 (returned from syscall execve), 0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2
> 
> and an x86 binary (on an actual x86 kernel, not on top of an x86-64
> kernel):
> 
> 
>      $ ./gdb -q -nx --data-directory=data-directory ./a.out
>      Reading symbols from ./a.out...
>      (gdb) catch syscall execve
>      Catchpoint 1 (syscall 'execve' [11])
>      (gdb) r
>      Starting program: /home/simark/build/binutils-gdb/gdb/a.out
> 
>      Catchpoint 1 (call to syscall execve), 0xb7fddcb0 in __kernel_vsyscall ()
>      (gdb) c
>      Continuing.
>      process 3734 is executing new program: /home/simark/build/binutils-gdb/gdb/a.out
> 
>      Catchpoint 1 (returned from syscall execve), 0xb7fdec60 in ?? () from /lib/ld-linux.so.2
> 
> In both cases, we see the execve syscall return at the entry point of
> the dynamic linker/loader.  I tested on aarch64 too, same thing.
> 
> I indeed see that on powerpc we don't get the return:
> 
>      $ ./gdb -q -nx --data-directory=data-directory ./a.out
>      Reading symbols from ./a.out...
>      (gdb) catch syscall execve
>      Catchpoint 1 (syscall 'execve' [11])
>      (gdb) r
>      Starting program: /home/simark/build/binutils-gdb/gdb/a.out
> 
>      Catchpoint 1 (call to syscall execve), 0x00007ffff7e6f18c in execve () from /lib64/libc.so.6
>      (gdb) c
>      Continuing.
>      process 98693 is executing new program: /home/simark/build/binutils-gdb/gdb/a.out
> 
>      Catchpoint 1 (call to syscall execve), 0x00007ffff7e6f18c in execve () from /lib64/libc.so.6
> 
> The behavior on powerpc sounds like a bug to me, and adjusting the test
> like this patch did just covers it up.  It doesn't make sense for that
> behavior to be different per arch, for the same OS.
> 
> 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
> :).

I do think this is likely a kernel bug.  In FreeBSD's case we report a single
event for both the syscall exit and exec event (but set flags to indicate that
both events are present.. in practice for GDB I think this means that on
FreeBSD we only report the exec event.  Not sure if it would be more correct
to report two events to the core in that case.)  I do think that a given OS
should probably be consistent here across architectures.

-- 
John Baldwin

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

[Carl Love]

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

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

[Carl Love]

On Tue, 2021-11-23 at 14:34 -0800, John Baldwin wrote:
> > > 

<snip>

> On 11/23/21 12:34 PM, Simon Marchi wrote:
> > 
> > The behavior on powerpc sounds like a bug to me, and adjusting the
> > test
> > like this patch did just covers it up.  It doesn't make sense for
> > that
> > behavior to be different per arch, for the same OS.
> > 
> > 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
> > :).
> 
> I do think this is likely a kernel bug.  In FreeBSD's case we report
> a single
> event for both the syscall exit and exec event (but set flags to
> indicate that
> both events are present.. in practice for GDB I think this means that
> on
> FreeBSD we only report the exec event.  Not sure if it would be more
> correct
> to report two events to the core in that case.)  I do think that a
> given OS
> should probably be consistent here across architectures.
> 

So I sent out a preliminary patch for comments to revert the change and
make it an xfail.  

I was looking to see where I should file a bug.  The discussion has
said it is a kernel bug.  The Freebsd commit you pointed to is a distro
fix from what I can see?  So, is it really a linux kernel issue or
something that the distros handle?  I believe there is a ptrace code in
glib see that interacts with the result from the kernel, is that where
the fix should go to fix all arch?

Anyway, it isn't clear to me at the moment which bugzilla a bug should
be filed with.  Thoughts?

                        Carl

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

[John Baldwin]

On 11/24/21 9:46 AM, Carl Love wrote:
> On Tue, 2021-11-23 at 14:34 -0800, John Baldwin wrote:
>>>>
> 
> <snip>
> 
>> On 11/23/21 12:34 PM, Simon Marchi wrote:
>>>
>>> The behavior on powerpc sounds like a bug to me, and adjusting the
>>> test
>>> like this patch did just covers it up.  It doesn't make sense for
>>> that
>>> behavior to be different per arch, for the same OS.
>>>
>>> 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
>>> :).
>>
>> I do think this is likely a kernel bug.  In FreeBSD's case we report
>> a single
>> event for both the syscall exit and exec event (but set flags to
>> indicate that
>> both events are present.. in practice for GDB I think this means that
>> on
>> FreeBSD we only report the exec event.  Not sure if it would be more
>> correct
>> to report two events to the core in that case.)  I do think that a
>> given OS
>> should probably be consistent here across architectures.
>>
> 
> So I sent out a preliminary patch for comments to revert the change and
> make it an xfail.

For GDB I think you have to make it an xfail for powerpc.

> I was looking to see where I should file a bug.  The discussion has
> said it is a kernel bug.  The Freebsd commit you pointed to is a distro
> fix from what I can see?  So, is it really a linux kernel issue or
> something that the distros handle?  I believe there is a ptrace code in
> glib see that interacts with the result from the kernel, is that where
> the fix should go to fix all arch?

The FreeBSD commit isn't for a distro, it's for a different OS kernel
that supports (some) Linux binaries as an alternate userspace ABI.  For
the kernel bug you would need to file that with the Linux kernel maintainers
following the directions at
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

-- 
John Baldwin

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

[Simon Marchi]

On 2021-11-23 8:15 p.m., Carl Love wrote:
> 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.

If we can already determine that it's the kernel fault, then xfail is
appropriate.  But I haven't actually dug to find out who is at fault.

> 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 just filed it here: https://sourceware.org/bugzilla/show_bug.cgi?id=28623

> 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.

I try to look at this later.  For now I will push a revert patch, since
we agree on the fact that this is a bug (and the test should not expect
the buggy behavior).

Simon

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

[Carl Love]

Simon:

I split the latest patch so there is a separate revert patch and a
patch to make the Powerepc test a xfail.  Note, the revert patch only
reverts the part of the original patch that causes the regression test
on amd64.  

Let me know if the first patch looks OK to commit to mainline.

We can continue to discuss the second patch to decide if there is a
better implementation to add the xfail and if it really is a kernel
failure.

                     Carl 
--------------------------------------------------------------------
[PATCH 1/2] 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.

This patch just reverts the part of the commit that caused the regression
failure on amd64.  The change for the istarget powerpc64-*-linux* is not
being reverted.
---
 gdb/testsuite/gdb.base/catch-syscall.exp | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
index 016d0a698a6..cdd5e2aec47 100644
--- a/gdb/testsuite/gdb.base/catch-syscall.exp
+++ b/gdb/testsuite/gdb.base/catch-syscall.exp
@@ -348,9 +348,7 @@ 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"
-
-	# Check that the execve is called.
-	check_call_to_syscall "execve"
+	check_continue "execve"
 
 	# Continue to main so extended-remote can read files as needed.
 	# (Otherwise that "Reading" output confuses gdb_continue_to_end.)
-- 
2.30.2

-----------------------------------------------------------------------
[PATCH 2/2] gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp

Powerpc is not reporting the

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

as expected.  The issue appears to be with the kernel not returning the
expected result.  This patch marks the test failure as an xfail.

See gdb bugzilla https://sourceware.org/bugzilla/show_bug.cgi?id=28623
---
 gdb/testsuite/gdb.base/catch-syscall.exp | 37 ++++++++++++++++++++----
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
index cdd5e2aec47..0693f7afe27 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.  GDB bugzilla 28623.
+		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,11 +369,15 @@ 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"
-	check_continue "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.
 
-	# 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

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

[Carl Love]

Simon:

I sent the following two patches, the first to revert the change, the
second to make the failures xfail.   I haven't heard anything.  Please
let me know if the first patch to revert the test change is OK and I
will commit that.  We can then work more on deciding how to handle the
failure, i.e. patch 2.

                 Carl 
---------------------------------------------------

On Mon, 2021-11-29 at 08:46 -0800, Carl Love wrote:
> Simon:
> 
> I split the latest patch so there is a separate revert patch and a
> patch to make the Powerepc test a xfail.  Note, the revert patch only
> reverts the part of the original patch that causes the regression
> test
> on amd64.  
> 
> Let me know if the first patch looks OK to commit to mainline.
> 
> We can continue to discuss the second patch to decide if there is a
> better implementation to add the xfail and if it really is a kernel
> failure.
> 
>                      Carl 
> --------------------------------------------------------------------
> [PATCH 1/2] 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.
> 
> This patch just reverts the part of the commit that caused the
> regression
> failure on amd64.  The change for the istarget powerpc64-*-linux* is
> not
> being reverted.
> ---
>  gdb/testsuite/gdb.base/catch-syscall.exp | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp
> b/gdb/testsuite/gdb.base/catch-syscall.exp
> index 016d0a698a6..cdd5e2aec47 100644
> --- a/gdb/testsuite/gdb.base/catch-syscall.exp
> +++ b/gdb/testsuite/gdb.base/catch-syscall.exp
> @@ -348,9 +348,7 @@ 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"
> -
> -	# Check that the execve is called.
> -	check_call_to_syscall "execve"
> +	check_continue "execve"
>  
>  	# Continue to main so extended-remote can read files as needed.
>  	# (Otherwise that "Reading" output confuses
> gdb_continue_to_end.)
> -- 
> 2.30.2
> 
> -------------------------------------------------------------------
> ----
> [PATCH 2/2] gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp
> 
> Powerpc is not reporting the
> 
>   Catchpoint 1 (returned from syscall execve),  ....
> 
> as expected.  The issue appears to be with the kernel not returning
> the
> expected result.  This patch marks the test failure as an xfail.
> 
> See gdb bugzilla 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28623
> ---
>  gdb/testsuite/gdb.base/catch-syscall.exp | 37 ++++++++++++++++++++
> ----
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp
> b/gdb/testsuite/gdb.base/catch-syscall.exp
> index cdd5e2aec47..0693f7afe27 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.  GDB bugzilla 28623.
> +		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,11 +369,15 @@ 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"
> -	check_continue "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.
>  
> -	# 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

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

[Simon Marchi]

On 2021-11-29 11:46 a.m., Carl Love via Gdb-patches wrote:
> Simon:
> 
> I split the latest patch so there is a separate revert patch and a
> patch to make the Powerepc test a xfail.  Note, the revert patch only
> reverts the part of the original patch that causes the regression test
> on amd64.  
> 
> Let me know if the first patch looks OK to commit to mainline.
> 
> We can continue to discuss the second patch to decide if there is a
> better implementation to add the xfail and if it really is a kernel
> failure.
> 
>                      Carl 
> --------------------------------------------------------------------
> [PATCH 1/2] 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.
> 
> This patch just reverts the part of the commit that caused the regression
> failure on amd64.  The change for the istarget powerpc64-*-linux* is not
> being reverted.
> ---
>  gdb/testsuite/gdb.base/catch-syscall.exp | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
> index 016d0a698a6..cdd5e2aec47 100644
> --- a/gdb/testsuite/gdb.base/catch-syscall.exp
> +++ b/gdb/testsuite/gdb.base/catch-syscall.exp
> @@ -348,9 +348,7 @@ 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"
> -
> -	# Check that the execve is called.
> -	check_call_to_syscall "execve"
> +	check_continue "execve"
>  
>  	# Continue to main so extended-remote can read files as needed.
>  	# (Otherwise that "Reading" output confuses gdb_continue_to_end.)
> -- 
> 2.30.2

This was already done by this commit:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e19f8248297bb9864ff14368cc89d2446572837a

> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
> index cdd5e2aec47..0693f7afe27 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.  GDB bugzilla 28623.
> +		xfail $thistest
> +		return 0

This should check that the target is powerpc before doing the xfail, because
getting that result on any other architecture should result in a FAIL.  Probably
"[istarget "powerpc*-*-*"]".


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

Can this just be

  return [check_return_from_syscall $syscall $pattern] ?

Simon

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

[Carl Love]

Simon:

On Fri, 2021-12-10 at 13:36 -0500, Simon Marchi wrote:
> > +         -re -wrap ".*Breakpoint $decimal, main .*" {
> > +             # On Powerpc kernel does not report the returned from
> > syscall
> > +             # as expected by the test.  GDB bugzilla 28623.
> > +             xfail $thistest
> > +             return 0
> 
> This should check that the target is powerpc before doing the xfail,
> because
> getting that result on any other architecture should result in a
> FAIL.  Probably
> "[istarget "powerpc*-*-*"]".
> 

I added a check for istarget "powerpc64*-linux*".

< snip>

> >   
> >   # 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
> > +    }
> 
> Can this just be
> 
>   return [check_return_from_syscall $syscall $pattern] ?
> 
Yup, that works for me.

The updated patch is below.  It has been retested on PowerPC and Intel
with no new regressions.

Please let me know if it is OK to commit to gdb mainline.  Thanks.

                     Carl 
-----------------------------------------------------
gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp

Powerpc is not reporting the

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

as expected.  The issue appears to be with the kernel not returning the
expected result.  This patch marks the test failure as an xfail.

See gdb bugzilla https://sourceware.org/bugzilla/show_bug.cgi?id=28623
---
 gdb/testsuite/gdb.base/catch-syscall.exp | 38 ++++++++++++++++++++----
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
index cdd5e2aec47..76c5cfbc6d6 100644
--- a/gdb/testsuite/gdb.base/catch-syscall.exp
+++ b/gdb/testsuite/gdb.base/catch-syscall.exp
@@ -127,7 +127,29 @@ 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.  GDB bugzilla 28623.
+		puts "CARLL test failed"
+		if { [istarget "powerpc64*-linux*"] } {
+		    xfail $thistest
+		} else {
+		    fail $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 +164,7 @@ 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
+    return [check_return_from_syscall $syscall $pattern]
 }
 
 # Inserts a syscall catchpoint with an argument.
@@ -348,11 +370,15 @@ 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"
-	check_continue "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.
+
 
-	# 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

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

[Simon Marchi]

> gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp
> 
> Powerpc is not reporting the
> 
>   Catchpoint 1 (returned from syscall execve),  ....
> 
> as expected.  The issue appears to be with the kernel not returning the
> expected result.  This patch marks the test failure as an xfail.
> 
> See gdb bugzilla https://sourceware.org/bugzilla/show_bug.cgi?id=28623

When we got rid of ChangeLogs, we agreed on the format:

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623

when referring to bugzilla entries, let's use that.

> ---
>  gdb/testsuite/gdb.base/catch-syscall.exp | 38 ++++++++++++++++++++----
>  1 file changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp
> index cdd5e2aec47..76c5cfbc6d6 100644
> --- a/gdb/testsuite/gdb.base/catch-syscall.exp
> +++ b/gdb/testsuite/gdb.base/catch-syscall.exp
> @@ -127,7 +127,29 @@ 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

kernel -> the kernel
returned -> return

> +		# as expected by the test.  GDB bugzilla 28623.
> +		puts "CARLL test failed"

Leftover print.

Ok with those fixed.

Simon