From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3422 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: valgrind problems Date: Sun, 16 Jun 2013 10:36:17 -0400 Message-ID: <20130616143617.GM29800@brightrain.aerifal.cx> References: <1371333657.16425.350.camel@eris.loria.fr> <20130615221627.GB6548@port70.net> <20130616054006.GJ29800@brightrain.aerifal.cx> <1371367371.16425.363.camel@eris.loria.fr> <1371375118.16425.368.camel@eris.loria.fr> <1371379388.16425.372.camel@eris.loria.fr> <20130616113916.GC6548@port70.net> <1371392203.5692.82.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1371393390 17247 80.91.229.3 (16 Jun 2013 14:36:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Jun 2013 14:36:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3426-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 16 16:36:31 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UoE4E-0000ta-4K for gllmg-musl@plane.gmane.org; Sun, 16 Jun 2013 16:36:30 +0200 Original-Received: (qmail 9742 invoked by uid 550); 16 Jun 2013 14:36:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9731 invoked from network); 16 Jun 2013 14:36:29 -0000 Content-Disposition: inline In-Reply-To: <1371392203.5692.82.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3422 Archived-At: On Sun, Jun 16, 2013 at 04:16:43PM +0200, Jens Gustedt wrote: > Am Sonntag, den 16.06.2013, 13:39 +0200 schrieb Szabolcs Nagy: > > note that valgrind cannot emulate 80bit long double arithmetics > > (uses 64bit arithmetics instead) which breaks floating-point > > printf and strtod functions in musl (and most math code on x86 > > take slightly different code paths, some break badly) > > > > so valgrind has issues with floating-point code and there were > > limitations with threading as well > > Hm, valgrind seems to be *the* tool that is used everywhere. And on > glibc platforms it gives valuable insight and finds a lot of bugs. As > a naïve user of musl I would just expect it to work. I agree with you Jens -- user expectation is that valgrind should work (reasonable) and that valgrind is the best available tool for the job (which I believe is still true). However the floating point issue is real; valgrind will badly mis-execute code calling strtod or any of the scanf family of functions for floating point parsing, and will give subtly different results for a large portion of the math library. If anyone has a good working relationship with the valgrind team, I think we should raise this issue politely and aim to get correct floating point emulation added to valgrind. Obviously it may have to be done in software rather than using the host's floating point, but there's already a good, presumably bit-exact, GPLv2 implementation of i387 floating point emulation in the kernel if nobody wants to write a new one. Rich