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

Message ID 20171103134549.26512D804DA@oc3748833570.ibm.com
State New, archived
Headers

Commit Message

Ulrich Weigand Nov. 3, 2017, 1:45 p.m. UTC
  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
  

Comments

Yao Qi Nov. 3, 2017, 3 p.m. UTC | #1
On Fri, Nov 3, 2017 at 1:45 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
>
> Can you test whether the following patch fixes the problem on a
> real ARM system?
>

Yes, it fixes the test fail on armv{7,8}l-unknown-linux-gnueabihf.
  

Patch

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 */