From owner-svn-src-head@freebsd.org Mon Aug 29 15:06:02 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 647C6BC76E9 for ; Mon, 29 Aug 2016 15:06:02 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7D98F15 for ; Mon, 29 Aug 2016 15:06:01 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f47.google.com with SMTP id g62so102858996lfe.3 for ; Mon, 29 Aug 2016 08:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2XdnpEK0n97vEv42NRaA0mzewbc2WitrBwpelosfPxs=; b=USkhCehAd4rOGZFyl236BxMk6tJs3qNJWXQe+40tZHm/peAvfgGc/4j+ObaNFt52/c JDEGo5FesWj4o/BIfZRI+m9gU7etkSF9bYNv233JHUER6n6zHfsGuAzPBVq852Ra93gW O83csogQxhnMfOgvyNGekHvkluUPmdrdQsH3bfcn3ByYakX11bSaBvF84bhkgtsvJk3S QEhZ0jp+kPN6DQRkI1ZpMuqRqQtd9Tm8Jgh1efefKJprUNf2dSmQgr/z5TxS5DZEIwx/ UpiUXuBksBa1gwbdIIWpY7BilrGqDpo5R2OZCMCZ34HTbMdCvE5AEhRDqGzDp8pwX1tc 4j7w== X-Gm-Message-State: AE9vXwMhaob18zeDjABy7UjkVC7iDsKPmIC7s5UKYifcew+lrrxkSclaUBboBC0YKR69sg== X-Received: by 10.25.21.32 with SMTP id l32mr5848024lfi.158.1472483153332; Mon, 29 Aug 2016 08:05:53 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id h62sm6475111lji.28.2016.08.29.08.05.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 08:05:52 -0700 (PDT) Subject: Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys To: Konstantin Belousov , John Baldwin References: <201608272303.u7RN3N0D078505@repo.freebsd.org> <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org> <20160828015210.GI83214@kib.kiev.ua> <1595604.93PBdSz0kX@ralph.baldwin.cx> <20160829065813.GP83214@kib.kiev.ua> <20160829070715.GQ83214@kib.kiev.ua> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: <66844e3f-0e62-aaa2-3c27-3d3063a51c8e@freebsd.org> Date: Mon, 29 Aug 2016 18:05:50 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160829070715.GQ83214@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 15:06:02 -0000 On 29.08.2016 10:07, Konstantin Belousov wrote: > On Mon, Aug 29, 2016 at 09:58:13AM +0300, Konstantin Belousov wrote: >> On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote: >>> OTOH, given that we explicitly documented it as not being true, I suspect >>> any applications that are using ptrace() are going off the documentation, not >>> the implementation artifact. Note that Linux's ptrace() documents the same >>> requirement as before this change (caller is required to clear errno), so I >>> doubt there is any actual software out there that expects the >>> FreeBSD-specific behavior. Given that and the extra maintenance overhead of >>> having to dink with errno in assembly on X architectures, I'd rather we keep >>> the old language in the manpage and remove the 'errno' frobbing in the system >>> call wrappers. To be honest, my first response to this commit was one of >>> surprise that we modify errno directly as that is inconsistent with other >>> system calls. (I haven't looked to see if any other system call wrappers >>> modify errno for non-error cases.) >> >> The problematic calls are PT_PEEK_I and PT_PEEK_D, as far as I understand. >> >> I dug into the ptrace(2) consumers, I found a lot of things using >> it which I would not expect to use, besides usual suspects of gdb >> lldb libunwind reptyr etc. Most surprising was that even high-profile >> consumers including gdb sometimes fail to check errno after PT_PEEK. On >> the other hand, I did not found a case in gdb where errno is checked >> after PT_PEEK but not zeroed before the syscall. >> >> I almost agreed with you after the reading, but then I decided to look >> into glibc just in case. What I found there is really fascinating. >> From glibc/sysdeps/unix/sysv/linux: >> res = INLINE_SYSCALL (ptrace, 4, request, pid, addr, data); >> if (res >= 0 && request > 0 && request < 4) >> { >> __set_errno (0); >> return ret; >> } >> #define PTRACE_PEEKTEXT 1 >> #define PTRACE_PEEKDATA 2 >> #define PTRACE_PEEKUSR 3 >> >> In the end, I might consider changing the ptrace wrappers into >> consolidated C source, it would look like that >> >> int >> ptrace(int request, pid_t pid, caddr_t addr, int data) >> { >> >> errno = 0; >> return (__sys_ptrace(request, pid, addr, data)); >> } > > And Solaris libc, where ptrace() is the wrapper around procfs, starts its > implementation this way: > usr/src/lib/libc/i386/sys/ptrace.c > /* > * Process the request. > */ > errno = 0; > switch (request) { > case 1: /* PTRACE_PEEKTEXT */ > case 2: /* PTRACE_PEEKDATA */ > No surprise since they all share the same initial implementation. You can add NetBSD and OpenBSD too. Errno clearing as undocumented side effect is not what we need, and every system documents that user must clear errno.