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

[Simon Marchi <simark@simark.ca>]

> 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