svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

[John Baldwin]

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