From owner-freebsd-threads@FreeBSD.ORG Wed May 4 22:22:59 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD0D616A4CE; Wed, 4 May 2005 22:22:59 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0603343D5C; Wed, 4 May 2005 22:22:59 +0000 (GMT) (envelope-from das@freebsd.org) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j44MIPO4022800; Wed, 4 May 2005 18:18:25 -0400 (EDT) (envelope-from das@freebsd.org) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j44MIPko022799; Wed, 4 May 2005 18:18:25 -0400 (EDT) (envelope-from das@freebsd.org) Date: Wed, 4 May 2005 18:18:25 -0400 From: David Schultz To: Daniel Eischen Message-ID: <20050504221825.GA22732@VARK.MIT.EDU> References: <20050504205745.GH76171@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Marc Olzheim cc: freebsd-threads@freebsd.org Subject: Re: Floating point exceptions with -pthread X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:22:59 -0000 On Wed, May 04, 2005, Daniel Eischen wrote: > On Wed, 4 May 2005, Marc Olzheim wrote: > > > On Wed, May 04, 2005 at 10:22:00PM +0200, Marc Olzheim wrote: > > > So it really seems to be in the floorf() and ceilf() code. > > > > Say, isn't that instruction supposed to read 'flds -8(%ebp);' ? (mark > > the '-') > > No, 8(%ebp) is where the function's argument is (the first > instruction is a pushl, then %ebp is assigned from %esp). Yeah, that part is fine. The one odd thing I notice as a glance back at the code is that it uses -12(%ebp) and -16(%ebp) for temporary storage, instead of using -4(%ebp) and -8(%ebp) like the double versions. That's probably a cut-and-pasto on my part. This would explain the SIGFPEs if an asynchronous trap is causing the area just past the end of the stack to be overwritten, since only 8 bytes of stack are reserved. I'll take a closer look in a week or so...