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

[John Baldwin <jhb@FreeBSD.org>]

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