Date: Sun, 28 Aug 2016 04:52:10 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Andrey Chernov <ache@freebsd.org> Cc: 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 Message-ID: <20160828015210.GI83214@kib.kiev.ua> In-Reply-To: <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org> References: <201608272303.u7RN3N0D078505@repo.freebsd.org> <9bcf10db-de3f-33ce-e418-03ce3283ac90@freebsd.org> <20160828005637.GG83214@kib.kiev.ua> <59ac1812-7c77-b677-51c4-dcadc6b2be7f@freebsd.org> <20160828011501.GH83214@kib.kiev.ua> <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > >> C99 statement sounds stricter: > >> "The value of errno is zero at program startup, but is never set to zero > >> by any library function. 176)" > >> And syscall is not different from library function from C99 point of view. > > Point me to a single line in C99 which mentions ptrace(). > > > > Do you understand what did the commit changed, and what it did not ? > > Setting errno to zero before the syscall was the existing behaviour > > before the change, and I did not modified anything there. But previous > > wrapper set errno to zero in main thread even if called from some other > > thread, which was the bug fixed. > > If you may notice, I don't blame you and don't say that you introduce > setting errno to 0. I just want to bring your attention to the problem > while you are in that area and familiar with it. > I know that POSIX requires that POSIX-defined functions did not modified errno except on error, but it cannot require anything from functions which are not defined by the standard. I agree that it would be more consistent for ptrace(2) to not do that as well, but the behaviour is already there for 35 years and I do not view the 'consistency' as a serious reason to break ABI and introduce random failures for innocent consumers of it. On Sun, Aug 28, 2016 at 04:37:11AM +0300, Andrey Chernov wrote: > On 28.08.2016 4:25, Andrey Chernov wrote: > >> Point me to a single line in C99 which mentions ptrace(). > > Already done: ptrace == "any library function". *Shaking head* 'Library functions' references in the context of C99/C11 are implicitely limited to the functions defined by the chapter 7 Library of the standard. To play this sillyness to the end, please answer whether I am allowed to provide static functions definitions in the libraries headers ? E.g. clause 7.1.2 6 of C11 says: Any declaration of a library function shall have external linkage.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160828015210.GI83214>