From owner-cvs-all@FreeBSD.ORG Sun Jun 29 02:22:39 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D01B81065674; Sun, 29 Jun 2008 02:22:39 +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 91A998FC28; Sun, 29 Jun 2008 02:22:39 +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 m5T2NN9M039626; Sat, 28 Jun 2008 22:23:23 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m5T2NNTc039625; Sat, 28 Jun 2008 22:23:23 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 28 Jun 2008 22:23:23 -0400 From: David Schultz To: Bruce Evans Message-ID: <20080629022323.GA39584@zim.MIT.EDU> Mail-Followup-To: Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200806281758.m5SHwIl2083857@repoman.freebsd.org> <20080628180230.GA37313@zim.MIT.EDU> <20080629110524.W92369@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080629110524.W92369@delplex.bde.org> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/i386/gen _setjmp.S setjmp.S X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2008 02:22:39 -0000 On Sun, Jun 29, 2008, Bruce Evans wrote: > On Sat, 28 Jun 2008, David Schultz wrote: > > Don't clobber the FPU exception flags in longjmp. C99 requires them > > to remain unchanged. > > > >...but got cut off somehow. > > This is wrong. It breaks longjmp() from all COMPAT_[3-4] signal > handlers (not just ones for SIGFPE). I don't like the corresponding > change for amd64 either, and only approved it since amd64 doesn't > support COMPAT_[3-4] signal handlers. How is it possible for an application linked against an 8.X libc, and which is doing anything even remotely close to reasonable, to get COMPAT_3 or COMPAT_4 signal behavior?