From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 766E93858D28 for ; Tue, 23 Nov 2021 20:34:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 766E93858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5FBF71EDEE; Tue, 23 Nov 2021 15:34:09 -0500 (EST) Subject: Re: [PATCH] gdb fix for catch-syscall.exp To: John Baldwin , Carl Love , gdb-patches@sourceware.org Cc: Rogerio Alves References: <3b8e450b9fb4f4bec97a6bfbe6e6a4816be780ee.camel@us.ibm.com> <4d51616392553dd308672f65f18909ebf0513fc0.camel@us.ibm.com> <95fbffc3-8d30-6e75-4f52-f6e534a13b20@FreeBSD.org> From: Simon Marchi Message-ID: Date: Tue, 23 Nov 2021 15:34:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <95fbffc3-8d30-6e75-4f52-f6e534a13b20@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 20:34:11 -0000 > 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