From owner-freebsd-standards@FreeBSD.ORG Mon Jun 16 11:07:04 2008 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 559F31065674 for ; Mon, 16 Jun 2008 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4512D8FC35 for ; Mon, 16 Jun 2008 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5GB74Lt036865 for ; Mon, 16 Jun 2008 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5GB7359036861 for freebsd-standards@FreeBSD.org; Mon, 16 Jun 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Jun 2008 11:07:03 GMT Message-Id: <200806161107.m5GB7359036861@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 11:07:04 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec f stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h 50 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Jun 16 17:20:01 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A915106566B for ; Mon, 16 Jun 2008 17:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B88E8FC16 for ; Mon, 16 Jun 2008 17:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5GHK1en000179 for ; Mon, 16 Jun 2008 17:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5GHK1Jm000178; Mon, 16 Jun 2008 17:20:01 GMT (envelope-from gnats) Resent-Date: Mon, 16 Jun 2008 17:20:01 GMT Resent-Message-Id: <200806161720.m5GHK1Jm000178@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Vlad GALU Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02DF91065676 for ; Mon, 16 Jun 2008 17:10:09 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id E15B58FC1A for ; Mon, 16 Jun 2008 17:10:08 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m5GHA8Ru016721 for ; Mon, 16 Jun 2008 17:10:08 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.2/8.14.1/Submit) id m5GHA8KW016720; Mon, 16 Jun 2008 17:10:08 GMT (envelope-from nobody) Message-Id: <200806161710.m5GHA8KW016720@www.freebsd.org> Date: Mon, 16 Jun 2008 17:10:08 GMT From: Vlad GALU To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/124647: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 17:20:01 -0000 >Number: 124647 >Category: standards >Synopsis: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 16 17:20:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Vlad GALU >Release: RELENG_7 >Organization: Agile Networks >Environment: FreeBSD joint.dudu.ro 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat May 24 10:14:41 EEST 2008 root@joint.dudu.ro:/usr/src/sys/amd64/compile/JOINT amd64 >Description: The libstdc++ shipped with gcc 4.x supports some new associative containers, such as Patricia tries. The headers in /usr/include/c++/4.2/ext/pb_ds are incorrectly installed, as they have dependencies to other headers which are missing from the base system. >How-To-Repeat: Install FreeBSD 7.x :) >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Mon Jun 16 19:35:33 2008 Return-Path: Delivered-To: standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25E27106564A; Mon, 16 Jun 2008 19:35:33 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id DB8CB8FC1D; Mon, 16 Jun 2008 19:35:32 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m5GJD8rw025336; Mon, 16 Jun 2008 15:13:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m5GJD8Yb025335; Mon, 16 Jun 2008 15:13:08 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 16 Jun 2008 15:13:08 -0400 From: David Schultz To: standards@FreeBSD.ORG, amd64@FreeBSD.ORG Message-ID: <20080616191308.GA25248@zim.MIT.EDU> Mail-Followup-To: standards@FreeBSD.ORG, amd64@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: saving FPU state in setjmp/longjmp X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 19:35:33 -0000 Are setjmp/longjmp supposed to save and restore the FPU control word (rounding mode, exception masks, etc.)? They're specifically not supposed to touch the status word, and one would think that they shouldn't touch the control word either. From a pragmatic point of view, most apps don't touch the FP control word anyway, and the few that do are better off with fegetenv/fesetenv and friends. A brief survey of setjmp/longjmp implementations indicates: - freebsd/arm saves and restores the FPU status word, which is wrong. - freebsd/i386 and freebsd/amd64 save and restore the x87 control word but not the SSE control word, which is half wrong in one direction or the other. - freebsd/everything-else don't touch the FPU. - linux doesn't touch the FPU. - solaris doesn't touch the FPU. So the real question is whether to remove the part of setjmp and longjmp that fiddle with the x87 control word, or whether to extend these functions to also save and restore the SSE control word. The fact that SSE has been around for a while and nobody has noticed the breakage suggests that either change should have minimal impact on compatibility. From owner-freebsd-standards@FreeBSD.ORG Tue Jun 17 01:03:19 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352E61065670; Tue, 17 Jun 2008 01:03:19 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA178FC1B; Tue, 17 Jun 2008 01:03:19 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5H13I0S080292; Tue, 17 Jun 2008 01:03:18 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5H13Ij4080288; Tue, 17 Jun 2008 01:03:18 GMT (envelope-from kan) Date: Tue, 17 Jun 2008 01:03:18 GMT Message-Id: <200806170103.m5H13Ij4080288@freefall.freebsd.org> To: galu@agilenetworks.ro, kan@FreeBSD.org, freebsd-standards@FreeBSD.org, kan@FreeBSD.org From: kan@FreeBSD.org Cc: Subject: Re: standards/124647: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 01:03:19 -0000 Synopsis: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) State-Changed-From-To: open->patched State-Changed-By: kan State-Changed-When: Mon Jun 16 22:57:53 UTC 2008 State-Changed-Why: Patched in -current, will MFC shortly. Responsible-Changed-From-To: freebsd-standards->kan Responsible-Changed-By: kan Responsible-Changed-When: Mon Jun 16 22:57:53 UTC 2008 Responsible-Changed-Why: Patched in -current, will MFC shortly. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=124647 From owner-freebsd-standards@FreeBSD.ORG Tue Jun 17 08:10:06 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67CC710656B0 for ; Tue, 17 Jun 2008 08:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9D38FC23 for ; Tue, 17 Jun 2008 08:10:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5H8A6rS081299 for ; Tue, 17 Jun 2008 08:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5H8A6ET081298; Tue, 17 Jun 2008 08:10:06 GMT (envelope-from gnats) Date: Tue, 17 Jun 2008 08:10:06 GMT Message-Id: <200806170810.m5H8A6ET081298@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: dfilter@FreeBSD.org (dfilter service) Cc: Subject: Re: standards/122051: commit references a PR X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 08:10:06 -0000 The following reply was made to PR standards/122051; it has been noted by GNATS. From: dfilter@FreeBSD.org (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: standards/122051: commit references a PR Date: Tue, 17 Jun 2008 06:33:27 +0000 (UTC) davidxu 2008-06-17 06:26:29 UTC FreeBSD src repository Modified files: include Makefile unistd.h lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c Added files: include spawn.h lib/libc/gen posix_spawn.c Log: SVN rev 179838 on 2008-06-17 06:26:29Z by davidxu Add POSIX routines called posix_spawn() and posix_spawnp(), which can be used as replacements for exec/fork in a lot of cases. This change also added execvpe() which allows environment variable PATH to be used for searching executable file, it is used for implementing posix_spawnp(). PR: standards/122051 Revision Changes Path 1.280 +1 -1 src/include/Makefile 1.1 +115 -0 src/include/spawn.h (new) 1.88 +1 -0 src/include/unistd.h 1.136 +2 -2 src/lib/libc/gen/Makefile.inc 1.11 +22 -0 src/lib/libc/gen/Symbol.map 1.27 +14 -3 src/lib/libc/gen/exec.3 1.24 +22 -9 src/lib/libc/gen/exec.c 1.1 +472 -0 src/lib/libc/gen/posix_spawn.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-standards@FreeBSD.ORG Wed Jun 18 05:39:03 2008 Return-Path: Delivered-To: standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA789106567B; Wed, 18 Jun 2008 05:39:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC148FC1B; Wed, 18 Jun 2008 05:39:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5HEwTUH012416; Wed, 18 Jun 2008 00:58:29 +1000 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5HEwO6Z013391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2008 00:58:26 +1000 Date: Wed, 18 Jun 2008 00:58:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20080616191308.GA25248@zim.MIT.EDU> Message-ID: <20080617225302.Y52409@delplex.bde.org> References: <20080616191308.GA25248@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: amd64@FreeBSD.org, standards@FreeBSD.org Subject: Re: saving FPU state in setjmp/longjmp X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 05:39:03 -0000 On Mon, 16 Jun 2008, David Schultz wrote: > Are setjmp/longjmp supposed to save and restore the FPU control > word (rounding mode, exception masks, etc.)? They're specifically > not supposed to touch the status word, and one would think that s/specifically not supposed to/unspecifically supposed to/ (C99 footnote 212 -- see below) > they shouldn't touch the control word either. From a pragmatic > point of view, most apps don't touch the FP control word anyway, > and the few that do are better off with fegetenv/fesetenv and friends. All my tests would fail if longjmp() didn't restore the control word. longjmp() from a signal handler can't possibly work unless the control word is restored, and my tests reduce to little more than testing this. longjmp() from a signal handler also needs to touch the status word to work -- it needs to at least clear the exception flags; on i386 it has used fninit to reset the entire FP status word for 15+ years since I fixed it, since this seemed to be the fastest way of resetting enough. More details: - long ago, the FP state in signal handlers was fairly broken -- it was the same as the preempted state except for special breakage (clearing) of the exception flags. My tests were written at this time. - longjump() from a signal handler thus restored the control word at the time of the setjmp(). The fninit in the i386 version of it prevents it keeping the (specially broken) status word at the time of the signal, so the exception flags are normally already clear. - Return from a signal handler (which gives undefined behaviour in most cases including all returns from SIGFPU handlers, especially in plain C99) gave reasonable behaviour -- both the control and (broken) status word at the time of the signal were kept. The broken status word was required for signal handlers to use floating point without having to clear the exception flags themself (but any useful use of FP in a signal handler caused undefined behaviour slightly before the signal handler returned; specifically, it could trap due to the settings of the preempted state, and it could corrupt the preempted state), and as a side effect this kept the cleared flags on return so that the preempted code could also continue using floating point without clearing the flags. - A copy of status word at the time of the exception was kept in the "exception status word" in the pcb and passed to signal handlers in in the signal context. gdb supported printing the copy in the pcb only. To restore and/or fix up the original state, the e.s.w. had to be merged with the active s.w. I don't know of any software that did this. - now, signal handlers get a private (reset) state. This fixes some of the bugs described above and helps implement the following new ones: - longjmp() from a signal handler has unchanged behaviour, but now it is even more necessary to restore the control word at the time of the setjmp() and to do something to not keep the current status word, since the current control and status word are private to the signal handler. If longjmp() didn't touch the FP state, then the only way to get back to the preempted state after the longjmp() would be for the signal handler to restore the preempted state before the longjmp(). Signal handlers would have a hard time supporting this unportable complication, epsecially if they are not SIGFPE handers. - Return from a signal handler now restores the preempted FP state, modulo the breakage of the exception flags. When signal handlers started getting a reset state, I thought that the exception flags didn't need to be broken and changed npxtrap() to not break them, but this broke my tests of returning from SIGFPE handlers -- the tests just set a flag and return, but this no longer works since nothing including the tests clears the exception flags. (The tests also change the control word so that SIGFPE's for FP exceptions actually occur if the relevant exception flags are set; then if they remain set the fault repeats like an integer divide-by-0 SIGFPE.) - The exception status word and gdb's support for it have been lost (except in cvs history). Before clearing the flags, the flags are encoded in a number in the sigcontext. Then some info is lost when the flags are cleared. > A brief survey of setjmp/longjmp implementations indicates: > - freebsd/arm saves and restores the FPU status word, which is wrong. I think this is least broken. On i386, it is just an optimization to not save/restore the status word. Save/restore of it at least keeps any exception flags that are set at the time of the setjmp(). > - freebsd/i386 and freebsd/amd64 save and restore the x87 control word > but not the SSE control word, which is half wrong in one direction or > the other. These also reset the status word. This is mainly an optimization. When they were written, there was no support for FP state in C, so setjmp()/longjmp() only had to preserve as much FP state as a normal function. > - freebsd/everything-else don't touch the FPU. > - linux doesn't touch the FPU. > - solaris doesn't touch the FPU. All of these are broken. C99 unspecifically requires the arm behaviour: - in n869.txt, it requires restoring the "calling environment of the abstract machine" at the time of the setjmp(). - in n1124.pdf footnote 212, it specifically says that FP status flags are part of the calling env. Footnotes are not normative, and it doesn't seem to say anything specifically about the control word, but clearly the calling environment is intended to include all FP state. I must have interpreted the corresponding requirement in C90 loosely to justify not preserving any FP status when I fixed the i386 version to restore the control word. The abstract machine in C90 required little or nothing of FP. > So the real question is whether to remove the part of setjmp and > longjmp that fiddle with the x87 control word, or whether to > extend these functions to also save and restore the SSE control > word. The fact that SSE has been around for a while and nobody has > noticed the breakage suggests that either change should have > minimal impact on compatibility. According to C99, all FP state must be preserved, but we can still avoid preserving data registers and some perhaps other details that aren't part of the abstract machine. Breakage of the exception flags is rarely observed since no one uses these :-). Breakage of SIGFPE handlers is even more rarely observed since no one unmasks FP exceptions :-), and signals for FP exceptions give undefined behaviour anyway. The most interesting case is for longjmp() from a signal handler for non-FP signal. Some cases should work, without the signal handler knowing anything about FP. When the signal occurs, the FP state may be arbitrarily exotic, and it must become normal when longjmp() returns. The current i386 implementation gives this except it messes up the C99 exception flags. Bruce From owner-freebsd-standards@FreeBSD.ORG Sat Jun 21 13:16:13 2008 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52D5E106567B; Sat, 21 Jun 2008 13:16:13 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDD88FC19; Sat, 21 Jun 2008 13:16:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <485CFF1B.2080500@FreeBSD.org> Date: Sat, 21 Jun 2008 15:16:11 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: David Xu References: <485B7FFC.4040509@FreeBSD.org> <485B884A.70006@freebsd.org> In-Reply-To: <485B884A.70006@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , freebsd-standards@FreeBSD.org Subject: Re: execvpe port breakage X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2008 13:16:13 -0000 David Xu wrote: > Kris Kennaway wrote: >> http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.2008062001/deco-3.9_3.log >> >> >> Can someone please take a look? >> >> Kris >> > > Looks like the application defined its own version of execvpe() ? > I think we should change name execvpe in our header file to something > else to avoid conflict. > > David Xu > > There are a few others too: ./deco-3.9_3.log ./gdc-0.24_3.log ./ghc-6.8.2_1.log ./hugs98-200609_2.log ./jdk-1.6.0.3p4_2.log Also sysutils/screen. We could either patch these, try to alter the prototype of our execvpe to match, or rename/hide our version. I don't know if there is a standards-based argument. Kris From owner-freebsd-standards@FreeBSD.ORG Sat Jun 21 23:00:14 2008 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 721C1106566B for ; Sat, 21 Jun 2008 23:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 56B148FC0A for ; Sat, 21 Jun 2008 23:00:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5LN0EET057465 for ; Sat, 21 Jun 2008 23:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m5LN0Eso057464; Sat, 21 Jun 2008 23:00:14 GMT (envelope-from gnats) Resent-Date: Sat, 21 Jun 2008 23:00:14 GMT Resent-Message-Id: <200806212300.m5LN0Eso057464@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Tomohisa Tanaka Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 114C51065672 for ; Sat, 21 Jun 2008 22:59:47 +0000 (UTC) (envelope-from syl@ash.kaz.appi.keio.ac.jp) Received: from ash.kaz.appi.keio.ac.jp (ash.kaz.appi.keio.ac.jp [131.113.64.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD0608FC0A for ; Sat, 21 Jun 2008 22:59:46 +0000 (UTC) (envelope-from syl@ash.kaz.appi.keio.ac.jp) Received: from ash.kaz.appi.keio.ac.jp (localhost [127.0.0.1]) by ash.kaz.appi.keio.ac.jp (8.13.8/8.13.8) with ESMTP id m5LN3TlK074704 for ; Sun, 22 Jun 2008 08:03:29 +0900 (JST) (envelope-from syl@ash.kaz.appi.keio.ac.jp) Received: (from syl@localhost) by ash.kaz.appi.keio.ac.jp (8.13.8/8.13.8/Submit) id m5LN3TR6074703; Sun, 22 Jun 2008 08:03:29 +0900 (JST) (envelope-from syl) Message-Id: <200806212303.m5LN3TR6074703@ash.kaz.appi.keio.ac.jp> Date: Sun, 22 Jun 2008 08:03:29 +0900 (JST) From: Tomohisa Tanaka To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: standards/124860: flockfile(3) doesn't work when the memory has been exhausted. X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tomohisa Tanaka List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2008 23:00:14 -0000 >Number: 124860 >Category: standards >Synopsis: flockfile(3) doesn't work when the memory has been exhausted. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 21 23:00:13 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Tomohisa Tanaka >Release: FreeBSD 6.3-RELEASE i386 >Organization: >Environment: System: FreeBSD freebsd.localdomain 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: When the flockfile(3) acquires a lock, and the specified stream has never locked, and the memory has been exhausted, flockfile(3) returns without the stream locked. The flockfile(3) calls _pthread_mutex_lock() according to the file /usr/src/lib/libc/stdio/_flock_stub.c, as follows. /usr/src/lib/libc/stdio/_flock_stub.c: 69 #define _lock _extra ... 83 _pthread_mutex_lock(&fp->_lock->fl_mutex); The _pthread_mutex_lock() does never fail if fp->_extra->fl_mutex has already been dynamically initialized. However, if fp->_extra->fl_mutex has been statically initialized, the _pthread_mutex_lock() tries to perform the dynamic initialization of it by calling the pthread_mutex_init(3), as follows. /usr/src/lib/libpthread/thread/thr_mutex.c: 302 static int 303 init_static_private(struct pthread *thread, pthread_mutex_t *mutex) 304 { ... 310 ret = pthread_mutex_init(mutex, &static_mattr); ... 317 } ... 849 int 850 _pthread_mutex_lock(pthread_mutex_t *m) 851 { ... 866 else if ((*m != NULL) || 867 ((ret = init_static_private(curthread, m)) == 0)) 868 ret = mutex_lock_common(curthread, m, NULL); ... 871 } When the memory has been exhausted, the pthread_mutex_init(3) returns ENOMEM. All mutexes of the stdio stream are statically initialized, according to the file /usr/src/lib/libc/stdio/findfp.c. >How-To-Repeat: % cat test.c #include #include #include #include #include static pthread_barrier_t barrier; static FILE *fp; static void * run(void *arg) { pthread_barrier_wait(&barrier); flockfile(fp); /* [1] */ return NULL; } int main(void) { pthread_t thread; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; void *p; size_t k; if (pthread_barrier_init(&barrier, NULL, 2) != 0) err(1, "pthread_barrier_init"); if (pthread_create(&thread, NULL, run, NULL) != 0) err(1, "pthread_create"); if ((fp = fopen("log", "w")) == NULL) err(1, "log"); #if 1 for (k = 1; k < 64; ++k) { while ((p = malloc(k)) != NULL) ; } /* * Now, we are in a special situation where the memory has been * extremely exhausted. Here, 'mutex' has not initialized with * pthread_mutex_init(3), so pthread_mutex_lock(3) as follows will * try to initialize "mutex" using pthread_mutex_init(3) internally. * However, malloc(3) within the pthread_mutex_init(3) returns NULL, * and then pthread_mutex_lock(3) fails and returns ENOMEM. */ if ((errno = pthread_mutex_lock(&mutex)) != 0) { warn("pthread_mutex_lock"); } #endif flockfile(fp); /* [2] */ /* * Here, this main thread does NOT have the lock of "fp", because * pthread_mutex_lock(3) within flockfile(3) at [2] has failed. We * must remember "fp->_extra->fl_mutex" has not been initialized by * pthread_mutex_init(3) as well as "mutex". */ pthread_barrier_wait(&barrier); /* * Another thread will call flockfile(3) at [1], but it returns * immediately. No thread can get the lock of 'fp' in this * situation. If we comment out from "#if 1" to "#endif", a * deadlock occurs. */ pthread_join(thread, NULL); return 0; } % cat test.sh #!/bin/sh ulimit -v 10000 ./a.out % gcc -pthread test.c % sh test.sh a.out: pthread_mutex_lock: Cannot allocate memory % >Fix: I think that the function __sfp() of /usr/src/lib/libc/stdio/findfp.c must perform the dynamic initialization of fp->_extra->fl_mutex, if it has been only statically initialized. And if it failed, __sfp() must return NULL. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Sat Jun 21 23:24:41 2008 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C81701065676; Sat, 21 Jun 2008 23:24:41 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF628FC1E; Sat, 21 Jun 2008 23:24:40 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=62334 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KAC2y-000DUh-RW; Sat, 21 Jun 2008 22:59:04 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m5LMwoEZ021201; Sun, 22 Jun 2008 02:58:50 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m5LMwoOP021200; Sun, 22 Jun 2008 02:58:50 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Sun, 22 Jun 2008 02:58:50 +0400 From: Ruslan Ermilov To: Kris Kennaway Message-ID: <20080621225850.GA21194@team.vega.ru> References: <485B7FFC.4040509@FreeBSD.org> <485B884A.70006@freebsd.org> <485CFF1B.2080500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485CFF1B.2080500@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current , freebsd-standards@freebsd.org Subject: Re: execvpe port breakage X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2008 23:24:41 -0000 On Sat, Jun 21, 2008 at 03:16:11PM +0200, Kris Kennaway wrote: > David Xu wrote: > > Kris Kennaway wrote: > >> http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.2008062001/deco-3.9_3.log > >> > >> > >> Can someone please take a look? > >> > >> Kris > >> > > > > Looks like the application defined its own version of execvpe() ? > > I think we should change name execvpe in our header file to something > > else to avoid conflict. > > > > David Xu > > > > > > There are a few others too: > > ./deco-3.9_3.log > ./gdc-0.24_3.log > ./ghc-6.8.2_1.log > ./hugs98-200609_2.log > ./jdk-1.6.0.3p4_2.log > > Also sysutils/screen. > > We could either patch these, try to alter the prototype of our execvpe > to match, or rename/hide our version. I don't know if there is a > standards-based argument. > I've fixed the deco port to detect if the system has execvpe() implementation. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer