This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC v2][3/3] Target FP printing: Use floatformat_to_string in tdep code
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 17 Oct 2017 12:40:19 +0100
- Subject: Re: [RFC v2][3/3] Target FP printing: Use floatformat_to_string in tdep code
- Authentication-results: sourceware.org; auth=none
- References: <20171017090843.390EBD807C2@oc3748833570.ibm.com>
On Tue, 17 Oct 2017, Ulrich Weigand wrote:
> > I have now quickly checked it with a single target only and unfortunately
> > the layout still has changed, e.g. in gdb.base/callfuncs.exp it used to
> > be:
> >
> > [...]
> > f0: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001
> > f1: 0xbf50624d flt: -0.813999951
> > f2: 0x00000000 flt: 0 dbl: 0
> > f3: 0x00000000 flt: 0
> > f4: 0xffffffff flt: -nan dbl: -nan
> > f5: 0xffffffff flt: -nan
> > f6: 0xffffffff flt: -nan dbl: -nan
> > f7: 0xffffffff flt: -nan
> > [...]
> >
> > while now it is:
> >
> > [...]
> > f0: 0xd2f1a9fc flt: -5.18969491e+11 dbl: -0.001
> > f1: 0xbf50624d flt: -0.813999951
> > f2: 0x00000000 flt: 0 dbl: 0
> > f3: 0x00000000 flt: 0
> > f4: 0xffffffff flt: -nan(0x7fffff) dbl: -nan(0xfffffffffffff)
> > f5: 0xffffffff flt: -nan(0x7fffff)
> > f6: 0xffffffff flt: -nan(0x7fffff) dbl: -nan(0xfffffffffffff)
> > f7: 0xffffffff flt: -nan(0x7fffff)
> > [...]
> >
> > so it looks to me that the NaN formatter gets the character count wrong.
>
> I see. I guess we shouldn't use the special output strings at all
> when using formatted printing, but rely on the underlying printer
> to handle all cases. (This actually matches today's behavior of
> printf_command, which my patches inadvertently changed.)
>
> Can you verify using this additional patch on top of the series?
This indeed brings the original output back, although I think printing
the NaN payload does have a value.
Would it be a tough problem to have it printed according to the width
requested in the format specifier? We know it's always going to take less
than the maximum required for a floating-point number of the same
floating-point format.
As an independent change I think it would best be made with a separate
patch though.
Maciej