From owner-svn-src-head@freebsd.org Sun Aug 28 23:12:05 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 DF4B5BC5B77; Sun, 28 Aug 2016 23:12:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA96595C; Sun, 28 Aug 2016 23:12:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 58F6CB922; Sun, 28 Aug 2016 19:12:04 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Cc: Andrey Chernov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys Date: Sun, 28 Aug 2016 16:09:51 -0700 Message-ID: <1595604.93PBdSz0kX@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160828015210.GI83214@kib.kiev.ua> References: <201608272303.u7RN3N0D078505@repo.freebsd.org> <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org> <20160828015210.GI83214@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Sun, 28 Aug 2016 19:12:04 -0400 (EDT) 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: Sun, 28 Aug 2016 23:12:06 -0000 On Sunday, August 28, 2016 04:52:10 AM Konstantin Belousov wrote: > On Sun, Aug 28, 2016 at 04:25:46AM +0300, Andrey Chernov wrote: > > On 28.08.2016 4:15, Konstantin Belousov wrote: > > >> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to zero." > > > I am quite curious where ptrace(2) is defined by POSIX. > > > > POSIX just repeats C99 statement for its own functions, supporting this > > rule too, but C99 rule is more general and related to any library functions. > > > > >> POSIX: "For each thread of a process, the value of errno shall not be > > >> affected by function calls or assignments to errno by other threads." > > > And ? What should the citation add new to the substance > > > of the code change ? > > > > This is for your comment "On both i386 and amd64, the errno symbol was > > directly referenced, which only works correctly in single-threaded > > process." > I still do not understand what you want to say there. Errno as the > symbol existing in the symbol table of libc, gives 'POSIX errno' value > for the main thread. Preprocessor definition converts C language > accesses to errno into some indirections which result in accesses to > per-thread errno location. The bug in x86 asm code was due to direct > usage of errno. > > What POSIX requires from the C-level errno symbol does not define a > semantic for the memory location pointed to by the errno sym-table > symbol. > > And amusingly, all other arches did it right, except aarch64 and risc-v > copied from aarch64. They lack the wrapper at all, I wrote aarch64 > ptrace.S already. 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.) -- John Baldwin