From owner-svn-src-all@freebsd.org Wed Nov 27 01:13:21 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 937751C6AF9; Wed, 27 Nov 2019 01:13:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47N2p93Fbbz4V3g; Wed, 27 Nov 2019 01:13:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4A26818E83; Wed, 27 Nov 2019 01:13:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id n4so23639582qte.2; Tue, 26 Nov 2019 17:13:21 -0800 (PST) X-Gm-Message-State: APjAAAVffg4NZvopi0vOSA8EtYoGuAPfxSZ7qK/YymJMLvJZ6IfEHTei elRbNIkbGwyTRopp87uyZTK/ljy1tzTjjKNazps= X-Google-Smtp-Source: APXvYqyC2wO36JRszudTdJ9tjgIW9Hcwpd96b4m2rSot8V39Q0GP5GQacQTz7K4+aeA+BLhFuJ846LnQApAgqWiGIu8= X-Received: by 2002:ac8:41cc:: with SMTP id o12mr37691084qtm.310.1574817200604; Tue, 26 Nov 2019 17:13:20 -0800 (PST) MIME-Version: 1.0 References: <201907152148.x6FLm3EL068478@repo.freebsd.org> <8b7be4f7-b8df-6951-5faa-7d35795a6a4c@FreeBSD.org> In-Reply-To: <8b7be4f7-b8df-6951-5faa-7d35795a6a4c@FreeBSD.org> From: Kyle Evans Date: Tue, 26 Nov 2019 19:13:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r350017 - in head: lib/libc/sys sys/kern sys/sys tests/sys/kern To: John Baldwin Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 01:13:21 -0000 On Tue, Nov 26, 2019 at 6:18 PM John Baldwin wrote: > > On 11/25/19 11:01 AM, Kyle Evans wrote: > > On Mon, Jul 15, 2019 at 4:48 PM John Baldwin wrote: > >> > >> Author: jhb > >> Date: Mon Jul 15 21:48:02 2019 > >> New Revision: 350017 > >> URL: https://svnweb.freebsd.org/changeset/base/350017 > >> > >> Log: > >> Add ptrace op PT_GET_SC_RET. > >> > >> This ptrace operation returns a structure containing the error and > >> return values from the current system call. It is only valid when a > >> thread is stopped during a system call exit (PL_FLAG_SCX is set). > >> > >> The sr_error member holds the error value from the system call. Note > >> that this error value is the native FreeBSD error value that has _not_ > >> been translated to an ABI-specific error value similar to the values > >> logged to ktrace. > >> > >> If sr_error is zero, then the return values of the system call will be > >> set in sr_retval[0] and sr_retval[1]. > >> > >> Reviewed by: kib > >> MFC after: 1 month > >> Sponsored by: DARPA > >> Differential Revision: https://reviews.freebsd.org/D20901 > >> > >> Modified: > >> head/lib/libc/sys/ptrace.2 > >> head/sys/kern/sys_process.c > >> head/sys/sys/ptrace.h > >> head/tests/sys/kern/ptrace_test.c > >> > > > > Hey John, > > > > Any objection to MFC'ing this to stable/12 at least? I've found this > > to be almost-required in the ptrace user I've been working on > > lately... I certainly ripped out plenty of hair before realizing that > > it wasn't detecting error returns properly. > > Hmm, I did have it in my queue, but not the most urgent priority. Are > you using truss or something else? You can achieve the same thing without > the new op, it just requires arch-specific code to fetch the error status > and return value from registers. > Alrighty- that's good to hear. =-) It's actually an out-of-tree ptrace(2) user that's executing syscalls in the process it's attaching to. It works most of the time because the syscalls it's executing don't generally fail (mmap a single page was the only use until I started dorking with it), so it's not quite worth the overhead of adding the arch-specific bits to detect error (it grabs the return value, at least) -- this is generally just a small nicety for those of us debugging it. Thanks, Kyle Evans