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

[John Baldwin <jhb@FreeBSD.org>]

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