This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pushed] Re: [RFC][08/19] Target FP: Use target format throughout expression parsing


Yao Qi wrote:
> On 17-10-25 15:35:24, Ulrich Weigand wrote:
> > > On 2017-10-09 02:12 PM, Joel Brobecker wrote:
> > > > One C++ thing I did notice but forgot to report...
> > > > 
> > > >> +floatformat_from_string (const struct floatformat *fmt, gdb_byte *out,
> > > >> +			 std::string in)
> > > > 
> > > > Again, to be double-checked, but I think you want to pass the argument
> > > > by reference in this case. Otherwise, you may end up having an overhead
> > > > with might not be necessary due to the creation of a copy of the string
> > > > being passed as argument here.
> > > > 
> > > 
> > > Indeed, it's good practice to pass constant strings (or other objects) as
> > > const references (const std::string &in).
> > 
> > I've now pushed this patch (using the const reference as suggested).
> > 
> 
> Hi Ulrich,
> this patch causes a regression on arm target,
> 
> PASS -> FAIL: gdb.base/bitops.exp: print value of 0.0 || 0
> 
> https://sourceware.org/ml/gdb-testers/2017-q4/msg03040.html
> Do you have any clues?

Huh.  It looks like this exposed a bug in convert_doublest_to_floatformat that
was already present: in the very specific case of converting a value of zero
into the floatformats_ieee_double_littlebyte_bigword format, the output
buffer was simply left uninitialized.  Existing callers didn't notice since
they had zeroed out the input buffer anyway ...

I was able to reproduce it without an ARM system:
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) set debug expression 1
(gdb) print 0.0
Dump of expression @ 0x3ae6e10, before conversion to prefix form:
        Language c, 4 elements, 16 bytes each.
        Index                Opcode         Hex Value  String Value
            0              OP_FLOAT  39  '...............
            1    <unknown 61822288>  61822288  PU..............
            2             BINOP_ADD  1  .........Q......
            3              OP_FLOAT  39  '...............
Dump of expression @ 0x3ae6e10, after conversion to prefix form:
Expression: `2.1219957909652723e-314'
        Language c, 4 elements, 16 bytes each.


            0  OP_FLOAT              Type @0x3af5550 (double), value 2.1219957909652723e-314
$1 = 2.1219957909652723e-314

Can you test whether the following patch fixes the problem on a
real ARM system?

Thanks,
Ulrich

diff --git a/gdb/doublest.c b/gdb/doublest.c
index fe9fc23..ef98dde 100644
--- a/gdb/doublest.c
+++ b/gdb/doublest.c
@@ -387,7 +387,7 @@ convert_doublest_to_floatformat (const struct floatformat *fmt,
     }
 
   if (dfrom == 0)
-    return;			/* Result is zero */
+    goto finalize_byteorder;	/* Result is zero */
   if (dfrom != dfrom)		/* Result is NaN */
     {
       /* From is NaN */

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]