From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118319 invoked by alias); 4 Oct 2017 22:26:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118303 invoked by uid 89); 4 Oct 2017 22:26:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*uweigand, achieved, fir, our X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Oct 2017 22:26:48 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id E85D2C9A1C94F; Wed, 4 Oct 2017 23:26:39 +0100 (IST) Received: from [10.20.78.146] (10.20.78.146) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.361.1; Wed, 4 Oct 2017 23:26:43 +0100 Date: Wed, 04 Oct 2017 22:26:00 -0000 From: "Maciej W. Rozycki" To: Ulrich Weigand CC: Subject: Re: [RFC][06/19] Target FP: Use print_floating in tdep code In-Reply-To: <20170905182100.37B12D8086F@oc3748833570.ibm.com> Message-ID: References: <20170905182100.37B12D8086F@oc3748833570.ibm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2017-10/txt/msg00097.txt.bz2 Hi Ulrich, Thank you for your effort in getting this area right, the limitations in our FP arithmetic handling really troubled me. > In addition, both mips-tdep and sh64-tdep use host FP to print > floating-point values. This patch changes them to print_floating as well. > Again, this may change the output format a bit, but in general it would > appear preferable to use the default print_floating now (this will also > now match how all other FP values are printed). I pushed your changes 01-06 combined through testing with a couple of MIPS/Linux targets, native and crossed (from x86-64), and all have consistently regressed in gdb.base/dfp-exprs.exp, e.g.: (gdb) p 1.2df -$1 = 1.2 -(gdb) PASS: gdb.base/dfp-exprs.exp: p 1.2df +$1 = +(gdb) FAIL: gdb.base/dfp-exprs.exp: p 1.2df p -1.2df -$2 = -1.2 -(gdb) PASS: gdb.base/dfp-exprs.exp: p -1.2df +$2 = +(gdb) FAIL: gdb.base/dfp-exprs.exp: p -1.2df i.e. values to be output are missing, numerous across this test case. No other regressions though. Also I find the new formatting of `info all-registers' output functionally regressed (rather than merely "changed a bit"), e.g.: - f0: 0x00000000 flt: 0 dbl: 0 - f1: 0x00000000 flt: 0 - f2: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001 - f3: 0xbf50624d flt: -0.813999951 + f0: 0x00000000 flt: 0 dbl: 0 + f1: 0x00000000 flt: 0 + f2: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001 + f3: 0xbf50624d flt: -0.813999951 or taking a complete listing what used to look like: (gdb) info all-registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 00000001 00000001 d2f1a9fc 00000000 00000000 00000fff 00000000 t0 t1 t2 t3 t4 t5 t6 t7 R8 00000000 00021000 00000000 00000417 00000000 8144f6e0 8122d6b8 00000000 s0 s1 s2 s3 s4 s5 s6 s7 R16 00000000 00000000 00000000 00500000 0052de28 0052e008 00000000 00000000 t8 t9 k0 k1 gp sp s8 ra R24 77db4000 77e3f390 00000000 00000000 0041e220 7fff6090 7fff6090 00405c2c status lo hi badvaddr cause pc 00009cf3 0046790f 00000005 00417004 00800024 00405c30 f0: 0x00000000 flt: 0 dbl: 0 f1: 0x00000000 flt: 0 f2: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001 f3: 0xbf50624d flt: -0.813999951 f4: 0x7ff80000 flt: nan dbl: nan f5: 0x7ff80000 flt: nan f6: 0x7ff80000 flt: nan dbl: nan f7: 0x7ff80000 flt: nan f8: 0x7ff80000 flt: nan dbl: nan f9: 0x7ff80000 flt: nan f10: 0x7ff80000 flt: nan dbl: nan f11: 0x7ff80000 flt: nan f12: 0x45a1cac1 flt: 5177.34424 dbl: 45.654000000000003 f13: 0x4046d3b6 flt: 3.10667181 f14: 0x70a3d70a flt: 4.05648183e+29 dbl: -67.659999999999997 f15: 0xc050ea3d flt: -3.26429677 f16: 0x7ff80000 flt: nan dbl: nan f17: 0x7ff80000 flt: nan f18: 0x7ff80000 flt: nan dbl: nan f19: 0x7ff80000 flt: nan f20: 0x7ff80000 flt: nan dbl: nan f21: 0x7ff80000 flt: nan f22: 0x7ff80000 flt: nan dbl: nan f23: 0x7ff80000 flt: nan f24: 0x7ff80000 flt: nan dbl: nan f25: 0x7ff80000 flt: nan f26: 0x7ff80000 flt: nan dbl: nan f27: 0x7ff80000 flt: nan f28: 0x7ff80000 flt: nan dbl: nan f29: 0x7ff80000 flt: nan f30: 0x7ff80000 flt: nan dbl: nan f31: 0x7ff80000 flt: nan fcsr fir restart 00800000 00f30000 00000000 (gdb) is now: (gdb) info all-registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 00000001 00000001 d2f1a9fc 00000000 00000000 00000fff 00000000 t0 t1 t2 t3 t4 t5 t6 t7 R8 00000000 00021000 00000000 00000417 00000000 8144f6e0 8122d6b8 00000000 s0 s1 s2 s3 s4 s5 s6 s7 R16 00000000 00000000 00000000 00500000 0052de28 0052e008 00000000 00000000 t8 t9 k0 k1 gp sp s8 ra R24 77db4000 77e3f390 00000000 00000000 0041e220 7fff6090 7fff6090 00405c2c status lo hi badvaddr cause pc 00009cf3 0046790f 00000005 00417004 00800024 00405c30 f0: 0x00000000 flt: 0 dbl: 0 f1: 0x00000000 flt: 0 f2: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001 f3: 0xbf50624d flt: -0.813999951 f4: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f5: 0x7ff80000 flt: nan(0x780000) f6: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f7: 0x7ff80000 flt: nan(0x780000) f8: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f9: 0x7ff80000 flt: nan(0x780000) f10: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f11: 0x7ff80000 flt: nan(0x780000) f12: 0x45a1cac1 flt: 5177.34424 dbl: 45.654000000000003 f13: 0x4046d3b6 flt: 3.10667181 f14: 0x70a3d70a flt: 4.05648183e+29 dbl: -67.659999999999997 f15: 0xc050ea3d flt: -3.26429677 f16: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f17: 0x7ff80000 flt: nan(0x780000) f18: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f19: 0x7ff80000 flt: nan(0x780000) f20: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f21: 0x7ff80000 flt: nan(0x780000) f22: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f23: 0x7ff80000 flt: nan(0x780000) f24: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f25: 0x7ff80000 flt: nan(0x780000) f26: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f27: 0x7ff80000 flt: nan(0x780000) f28: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f29: 0x7ff80000 flt: nan(0x780000) f30: 0x7ff80000 flt: nan(0x780000) dbl: nan(0x800007ff80000) f31: 0x7ff80000 flt: nan(0x780000) fcsr fir restart 00800000 00f30000 00000000 (gdb) I think we need to get the ability to align output (previously achieved with formatters, i.e. "%-17.9g" and "%-24.17g") restored; frankly I find the new format unreadable, which makes me consider it unacceptable. Let me know if I could help with either issue anyhow. NB while striving for FP arithmetic to match target hardware accurately we'll have to handle the two opposite qNaN vs sNaN encodings that the MIPS architecture now supports, i.e. the original IEEE 754-1985 format with the quiet bit being 0 and the recent IEEE 754-2008 format with the quiet bit being 1. This obviously has to be taken into account in calculations, according to the hardware mode being active (or the relevant ELF file header flag in the binary chosen to debug if not connected to any target), and I do hope MPFR can be switched at the run time to do the right thing. This can of course be the next step, once we've settled on the base implementation -- and I'll take care of the MIPS architecture bits. Maciej