From owner-freebsd-arm@FreeBSD.ORG Wed Jan 11 10:18:35 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16F43106566B; Wed, 11 Jan 2012 10:18:35 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id A27A88FC12; Wed, 11 Jan 2012 10:18:34 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id q0BAIXSi088505; Wed, 11 Jan 2012 11:18:33 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id q0BAIXKT088504; Wed, 11 Jan 2012 11:18:33 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 11 Jan 2012 11:18:33 +0100 From: Olivier Houchard To: David Schultz Message-ID: <20120111101833.GA88428@ci0.org> References: <20120108183605.GA36775@zim.MIT.EDU> <1326144525.2199.32.camel@revolution.hippie.lan> <20120111052634.GA96534@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120111052634.GA96534@zim.MIT.EDU> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 10:18:35 -0000 Hi David, On Wed, Jan 11, 2012 at 12:26:34AM -0500, David Schultz wrote: > Debugging it without hardware could be tedious, and I don't > actually have the time to dedicate to ARM development. But it's > encouraging that all the symbols resolve and nothing bad seems to > happen. Perhaps I can commit the softfloat bindings and one of > the ARM developers can track down the (hopefully simple) bugs in > softfloat or the bindings that prevent fenv.h from working. It's > bound to be better than the no-ops we have now, in any case. I'm fine with this, if it doesn't make things worse I'd rather not see this code lost. Regards, Olivier