[RFC][00/19] Target FP: Precise target floating-point emulation

[RFC][00/19] Target FP: Precise target floating-point emulation

[Ulrich Weigand]

[RFC][00/19] Target FP: Precise target floating-point emulation

GDB currently performs all floating-point operations (arithmetic, conversion,
printing and scanning) using the largest standard host floating-point type
(typedef'd as DOUBLEST).

While this used to be mostly OK for typical native debugging sessions
(since the host DOUBLEST is large enough to faithfully represent all
target data types) -- except possibly for some rounding differences --,
this can cause serious issues if that assumption doesn't hold:

- When remote debugging a target that has a data type larger than
  the host DOUBLEST, e.g. "long double" on s390 is IEEE-128, which
  cannot be represented in a DOUBLEST on a x86 host.

- Even in native debugging, if there is some non-standard type that
  does not fit into "long double", e.g. __float128 on x86 and ppc64.

This patch series addresses this problem by converting GDB to perform
all floating-operations by precisely emulation target arithmetic,
using the MPFR library.

In general, the idea of the patch series is to completely eliminate
DOUBLEST from the GDB source base, and instead hold all floating-point
values always in target binary format in a byte buffer.  A new file
target-float.{c,h} then implements all required operations on those
byte buffers.

Note that this is very similar to how GDB today already handles
*decimal* floating-point values.  In fact, the new target-float
operations support both binary and decimal types with the same
interface, which will allow to consolidate most handling of BFP
and DFP throughout GDB into single FP code paths.

Once this refactoring is complete, the only remaining use of DOUBLEST
will be in target-float.c, where it can then be replaced by MPFR.
(Use of MPFR is still optional, with a fall-back to the old DOUBLEST
code if MPFR is not available.  We may want to re-think this and
make MPFR required --- it should be available everywhere where GDB
can be built today.)

The patch series is laid out as follows:

00-02: Some preliminary clean up of binary FP handling.
03:    Some preliminary clean up of decimal FP handling.
05-07: Simplify and fix binary FP printing.
08:    Remove DOUBLEST from expression parsing and binary FP scanning.
09-12: Introduce target-float.{c,h} and move operations there.
13-14: Remove some remaining uses of DOUBLEST in the code base.
15-17: Final (trival) clean up patches.
18:    Remove doublest.{c,h} and dfp.{c,h}.
19:    Switch target-float.c to use MPFR if present.

Any comments welcome, in particular from the affected target and
language maintainers!

Tested by building with --enable-targets=all and running the test
suite without regressions on x86_64-linux, powerpc64le-linux,
and s390x-linux.

Bye,
Ulrich

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Eli Zaretskii]

> Date: Tue, 5 Sep 2017 20:20:30 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 
> This patch series addresses this problem by converting GDB to perform
> all floating-operations by precisely emulation target arithmetic,
> using the MPFR library.

In native debugging as well?  If so, wouldn't that make GDB
significantly slower in that case?

Thanks.

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Ulrich Weigand]

Eli Zaretskii wrote:
> > Date: Tue, 5 Sep 2017 20:20:30 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > This patch series addresses this problem by converting GDB to perform
> > all floating-operations by precisely emulation target arithmetic,
> > using the MPFR library.
> 
> In native debugging as well?

Currently, yes.  However, this can be fine-tuned as we like using the
new setup; we could fall back to host arithmetic in some cases.

Making that decision based on native vs. remote debugging does not
appear to be the correct choice here, in particular given the problems
pointed out in my original mail with *native* debugging if FP types
larger than "long double" are used (like __float128).

However, we could make a decision based on the particular target
*format* (e.g. whether it is equivalent to one of the available
host formats).  The question is whether this is worthwhile the
additional complication of code (and possibly test cases).

> If so, wouldn't that make GDB significantly slower in that case?

Of course, considering just one single arithmetic operation, a call
to MPFR is orders of magnitude slower than just doing the operation
in host format (often a single instruction).

But that is not the only question; the other question is how frequent
those operations are in the first place.  And from what I can tell,
all the "hot", performance critical paths in GDB do not perform any
FP operations at all in the first place.  Those are only done in
response to UI actions specifically involving FP values.

For example, the whole of the gdb.base test suite appears to be doing
less 100 instances of any base FP operation.  (This does not count FP
parsing or printing, which are a bit more frequent -- but for those
operations the performance difference between a native printf/scanf
and the corrsponding MPFR printf/scanf is much less in proportion.)
So there is no overall wall-clock performance difference visible.

Now, I'm sure one can construct cases where FP arithmetic operations
occur much more frequently -- but I'd prefer to see a case where it
actually matters in real life before deciding to implement the more
complicated solution described above.

Bye,
Ulrich

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

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Eli Zaretskii]

> Date: Wed, 6 Sep 2017 20:00:51 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
> 
> > > This patch series addresses this problem by converting GDB to perform
> > > all floating-operations by precisely emulation target arithmetic,
> > > using the MPFR library.
> > 
> > In native debugging as well?
> 
> Currently, yes.  However, this can be fine-tuned as we like using the
> new setup; we could fall back to host arithmetic in some cases.
> 
> Making that decision based on native vs. remote debugging does not
> appear to be the correct choice here, in particular given the problems
> pointed out in my original mail with *native* debugging if FP types
> larger than "long double" are used (like __float128).
> 
> However, we could make a decision based on the particular target
> *format* (e.g. whether it is equivalent to one of the available
> host formats).  The question is whether this is worthwhile the
> additional complication of code (and possibly test cases).
> 
> > If so, wouldn't that make GDB significantly slower in that case?
> 
> Of course, considering just one single arithmetic operation, a call
> to MPFR is orders of magnitude slower than just doing the operation
> in host format (often a single instruction).
> 
> But that is not the only question; the other question is how frequent
> those operations are in the first place.  And from what I can tell,
> all the "hot", performance critical paths in GDB do not perform any
> FP operations at all in the first place.  Those are only done in
> response to UI actions specifically involving FP values.

I'm sorry, but it doesn't feel right to me to slow down native
operations where they fit the bill.  I agree that native debugging
which manipulates FP data types not supported natively could or should
be emulated, but normal 'float', 'double', and 'long double' types
should IMO use native FP processing.  Besides the speed issue, that's
also the only practical way to make sure these operations are _always_
identical to what the debuggee's code does or will do.

> Now, I'm sure one can construct cases where FP arithmetic operations
> occur much more frequently -- but I'd prefer to see a case where it
> actually matters in real life before deciding to implement the more
> complicated solution described above.

I'm sorry, but slowing down GDB just because there's no evidence
someone needs the fast operation is not a good idea IMO.  We should
make GDB as fast as it can be regardless of any particular examples of
the need for a fast GDB.

In sum, I'm in favor of having MPFR support where native FP
calculations cannot be used or don't represent the target correctly,
but not where they can and do.

Thanks.

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Joel Brobecker]

> I'm sorry, but it doesn't feel right to me to slow down native
> operations where they fit the bill.  I agree that native debugging
> which manipulates FP data types not supported natively could or should
> be emulated, but normal 'float', 'double', and 'long double' types
> should IMO use native FP processing.  Besides the speed issue, that's
> also the only practical way to make sure these operations are _always_
> identical to what the debuggee's code does or will do.
> 
> > Now, I'm sure one can construct cases where FP arithmetic operations
> > occur much more frequently -- but I'd prefer to see a case where it
> > actually matters in real life before deciding to implement the more
> > complicated solution described above.
> 
> I'm sorry, but slowing down GDB just because there's no evidence
> someone needs the fast operation is not a good idea IMO.  We should
> make GDB as fast as it can be regardless of any particular examples of
> the need for a fast GDB.
> 
> In sum, I'm in favor of having MPFR support where native FP
> calculations cannot be used or don't represent the target correctly,
> but not where they can and do.

FWIW, I'm receptive to the fact that using native FP is indeed
a sure way to make sure we have the same behavior in GDB and
in the program. But on the other hand, we have to be careful
about the impact on code complexity. If having that functionality
makes the code harder to implement and maintain past a certain
degree, then I think it is OK to break the assumption, if there
was any, that GDB would perform the FP operation exactly the same
as on the host.

Performance is a non-aspect to me: We not doing millions of
these operations in a row. In the vast majority of situations,
it'll be a handful. Even if it MPFR cannot be as fast as
hardware, operations were timed to be less than a microsecond
for the common operations to a 100 digits, and with a couple
of exceptions where it takes about about 40 micro seconds to
compute to 100 digits, the rest is clocked at about 5-10 microseconds
per operation up to 100 digits.
http://www.mpfr.org/mpfr-3.1.0/timings.html

-- 
Joel

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Ulrich Weigand]

Joel Brobecker wrote:
> Eli Zaretskii wrote:
> > I'm sorry, but it doesn't feel right to me to slow down native
> > operations where they fit the bill.  I agree that native debugging
> > which manipulates FP data types not supported natively could or should
> > be emulated, but normal 'float', 'double', and 'long double' types
> > should IMO use native FP processing.  Besides the speed issue, that's
> > also the only practical way to make sure these operations are _always_
> > identical to what the debuggee's code does or will do.
> > 
> > > Now, I'm sure one can construct cases where FP arithmetic operations
> > > occur much more frequently -- but I'd prefer to see a case where it
> > > actually matters in real life before deciding to implement the more
> > > complicated solution described above.
> > 
> > I'm sorry, but slowing down GDB just because there's no evidence
> > someone needs the fast operation is not a good idea IMO.  We should
> > make GDB as fast as it can be regardless of any particular examples of
> > the need for a fast GDB.
> > 
> > In sum, I'm in favor of having MPFR support where native FP
> > calculations cannot be used or don't represent the target correctly,
> > but not where they can and do.
> 
> FWIW, I'm receptive to the fact that using native FP is indeed
> a sure way to make sure we have the same behavior in GDB and
> in the program. But on the other hand, we have to be careful
> about the impact on code complexity. If having that functionality
> makes the code harder to implement and maintain past a certain
> degree, then I think it is OK to break the assumption, if there
> was any, that GDB would perform the FP operation exactly the same
> as on the host.
> 
> Performance is a non-aspect to me: We not doing millions of
> these operations in a row. In the vast majority of situations,
> it'll be a handful. Even if it MPFR cannot be as fast as
> hardware, operations were timed to be less than a microsecond
> for the common operations to a 100 digits, and with a couple
> of exceptions where it takes about about 40 micro seconds to
> compute to 100 digits, the rest is clocked at about 5-10 microseconds
> per operation up to 100 digits.
> http://www.mpfr.org/mpfr-3.1.0/timings.html

I've just posted an updated set of patches that implements the
suggestion to use host FP if the format matches, and MPFR if not.
To keep code complexity down, this is done by encapsulating the
operations in an abstract base class with multiple implementations.
https://sourceware.org/ml/gdb-patches/2017-11/msg00323.html
https://sourceware.org/ml/gdb-patches/2017-11/msg00324.html

Does this address your concerns?  Any further comments welcome!

Bye,
Ulrich

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

Re: [RFC][00/19] Target FP: Precise target floating-point emulation

[Eli Zaretskii]

> Date: Thu, 16 Nov 2017 20:05:59 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: eliz@gnu.org (Eli Zaretskii), gdb-patches@sourceware.org
> 
> I've just posted an updated set of patches that implements the
> suggestion to use host FP if the format matches, and MPFR if not.
> To keep code complexity down, this is done by encapsulating the
> operations in an abstract base class with multiple implementations.
> https://sourceware.org/ml/gdb-patches/2017-11/msg00323.html
> https://sourceware.org/ml/gdb-patches/2017-11/msg00324.html
> 
> Does this address your concerns?

Yes, thank you very much.

Doc update to mention MPFR (Re: [RFC][00/19] Target FP: Precise target floating-point emulation)

[Ulrich Weigand]

Eli Zaretskii wrote:
> > Date: Thu, 16 Nov 2017 20:05:59 +0100 (CET)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > Cc: eliz@gnu.org (Eli Zaretskii), gdb-patches@sourceware.org
> > 
> > I've just posted an updated set of patches that implements the
> > suggestion to use host FP if the format matches, and MPFR if not.
> > To keep code complexity down, this is done by encapsulating the
> > operations in an abstract base class with multiple implementations.
> > https://sourceware.org/ml/gdb-patches/2017-11/msg00323.html
> > https://sourceware.org/ml/gdb-patches/2017-11/msg00324.html
> > 
> > Does this address your concerns?
> 
> Yes, thank you very much.

Thanks for confirming!

I just noticed that I forgot to update the docs to mention MPFR.
The following patch adds this to README and gdb.texinfo in the
same places where libexpat is mentioned.  It also add a brief
mention to NEWS.

Is this OK?

Thanks,
Ulrich


gdb/ChangeLog:

	* NEWS: Document use of GNU MPFR.
	* README: Likewise.
	* doc/gdb.texinfo: Likewise

Index: binutils-gdb/gdb/NEWS
===================================================================
--- binutils-gdb.orig/gdb/NEWS
+++ binutils-gdb/gdb/NEWS
@@ -3,6 +3,10 @@
 
 *** Changes since GDB 8.0
 
+* GDB now uses the GNU MPFR library, if available, to emulate target
+  floating-point arithmetic during expression evaluation when the target
+  uses different floating-point formats than the host.
+
 * GDB now supports access to the guarded-storage-control registers and the
   software-based guarded-storage broadcast control registers on IBM z14.
 
Index: binutils-gdb/gdb/README
===================================================================
--- binutils-gdb.orig/gdb/README
+++ binutils-gdb/gdb/README
@@ -89,6 +89,15 @@ features.  Expat will be linked in if it
 those features will be disabled.  The latest version of Expat should be
 available from `http://expat.sourceforge.net'.
 
+   GDB uses GNU MPFR, a library for multiple-precision floating-point
+computation with correct rounding, to emulate target floating-point
+arithmetic during expression evaluation when the target uses different
+floating-point formats than the host.  MPFR will be linked in if it is
+available at build time.  At least version 3.1 of GNU MPFR is required.
+If GNU MPFR it is not available, GDB will fall back to using host
+floating-point arithmetic.  The latest version of GNU MPFR should be
+available from `http://www.mpfr.org´.
+
    GDB can be used as a cross-debugger, running on a machine of one
 type while debugging a program running on a machine of another type.
 See below.
@@ -475,6 +484,16 @@ prefer; but you may abbreviate option na
      have libexpat installed, you can  get the latest version from
      http://expat.sourceforge.net.
 
+`--with-mpfr'
+     Build GDB with the GNU MPFR library.  (Done by default if
+     GNU MPFR is installed and found at configure time.)  This library
+     is used to emulate target floating-point arithmetic during expression
+     evaluation when the target uses different floating-point formats than
+     the host. At least version 3.1 of GNU MPFR is required.  If GNU MPFR
+     is not available, GDB will fall back to using host floating-point
+     arithmetic.  If your host does not have GNU MPFR installed, you can
+     get the latest version from http://www.mpfr.org.
+
 `--with-python[=PATH]'
      Build GDB with Python scripting support.  (Done by default if
      libpython is present and found at configure time.)  Python makes
Index: binutils-gdb/gdb/doc/gdb.texinfo
===================================================================
--- binutils-gdb.orig/gdb/doc/gdb.texinfo
+++ binutils-gdb/gdb/doc/gdb.texinfo
@@ -34270,6 +34270,22 @@ Branch trace (@pxref{Branch Trace Format
 @pxref{Branch Trace Configuration Format})
 @end itemize
 
+@item MPFR
+@anchor{MPFR}
+@value{GDBN} can use the GNU MPFR multiple-precision floating-point
+library.  This library may be included with your operating system
+distribution; if it is not, you can get the latest version from
+@url{http://www.mpfr.org}.  At least version 3.1 of GNU MPFR is
+required.  The @file{configure} script will search for this library
+in several standard locations; if it is installed in an unusual path,
+you can use the @option{--with-libmpfr-prefix} option to specify
+its location.
+
+GNU MPFR is used to emulate target floating-point arithmetic during
+expression evaluation when the target uses different floating-point
+formats than the host.  If GNU MPFR it is not available, GDB will
+fall back to using host floating-point arithmetic.
+
 @item zlib
 @cindex compressed debug sections 
 @value{GDBN} will use the @samp{zlib} library, if available, to read


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

Re: Doc update to mention MPFR (Re: [RFC][00/19] Target FP: Precise target floating-point emulation)

[Eli Zaretskii]

> Date: Mon, 20 Nov 2017 14:44:12 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> --- binutils-gdb.orig/gdb/NEWS
> +++ binutils-gdb/gdb/NEWS
> @@ -3,6 +3,10 @@
>  
>  *** Changes since GDB 8.0
>  
> +* GDB now uses the GNU MPFR library, if available, to emulate target
> +  floating-point arithmetic during expression evaluation when the target
> +  uses different floating-point formats than the host.
> +

This part is OK.

> +   GDB uses GNU MPFR, a library for multiple-precision floating-point
> +computation with correct rounding, to emulate target floating-point
> +arithmetic during expression evaluation when the target uses different
> +floating-point formats than the host.  MPFR will be linked in if it is
> +available at build time.  At least version 3.1 of GNU MPFR is required.
> +If GNU MPFR it is not available, GDB will fall back to using host
> +floating-point arithmetic.  The latest version of GNU MPFR should be
> +available from `http://www.mpfr.org´.
                                      ^
Some non-ASCII character sneaked in here.

> +`--with-mpfr'
> +     Build GDB with the GNU MPFR library.  (Done by default if
> +     GNU MPFR is installed and found at configure time.)  This library
> +     is used to emulate target floating-point arithmetic during expression
> +     evaluation when the target uses different floating-point formats than
> +     the host. At least version 3.1 of GNU MPFR is required.  If GNU MPFR

I would drop the reference to minimum supported MPFR version here: it
tends to become outdated as time goes by, and I believe the configure
script includes the necessary tests for what we need from MPFR, and
will reject versions that don't fit the bill.

(It is okay to have the version mentioned in NEWS, as that is a
one-time announcement.)

Also, please make sure there are 2 spaces between sentences.

> +@item MPFR
> +@anchor{MPFR}
> +@value{GDBN} can use the GNU MPFR multiple-precision floating-point
> +library.  This library may be included with your operating system
> +distribution; if it is not, you can get the latest version from
> +@url{http://www.mpfr.org}.  At least version 3.1 of GNU MPFR is
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Same here.

> +formats than the host.  If GNU MPFR it is not available, GDB will
                                                            ^^^
@value{GDBN}

The changes are okay with those gotchas fixed.

Thanks.

Re: Doc update to mention MPFR (Re: [RFC][00/19] Target FP: Precise target floating-point emulation)

[Ulrich Weigand]

Eli Zaretskii wrote:
> >  *** Changes since GDB 8.0
> >  
> > +* GDB now uses the GNU MPFR library, if available, to emulate target
> > +  floating-point arithmetic during expression evaluation when the target
> > +  uses different floating-point formats than the host.
> > +
> 
> This part is OK.
> 
> > +   GDB uses GNU MPFR, a library for multiple-precision floating-point
> > +computation with correct rounding, to emulate target floating-point
> > +arithmetic during expression evaluation when the target uses different
> > +floating-point formats than the host.  MPFR will be linked in if it is
> > +available at build time.  At least version 3.1 of GNU MPFR is required.
> > +If GNU MPFR it is not available, GDB will fall back to using host
> > +floating-point arithmetic.  The latest version of GNU MPFR should be
> > +available from `http://www.mpfr.org´.
>                                       ^
> Some non-ASCII character sneaked in here.
> 
> > +`--with-mpfr'
> > +     Build GDB with the GNU MPFR library.  (Done by default if
> > +     GNU MPFR is installed and found at configure time.)  This library
> > +     is used to emulate target floating-point arithmetic during expression
> > +     evaluation when the target uses different floating-point formats than
> > +     the host. At least version 3.1 of GNU MPFR is required.  If GNU MPFR
> 
> I would drop the reference to minimum supported MPFR version here: it
> tends to become outdated as time goes by, and I believe the configure
> script includes the necessary tests for what we need from MPFR, and
> will reject versions that don't fit the bill.
> 
> (It is okay to have the version mentioned in NEWS, as that is a
> one-time announcement.)
> 
> Also, please make sure there are 2 spaces between sentences.
> 
> > +@item MPFR
> > +@anchor{MPFR}
> > +@value{GDBN} can use the GNU MPFR multiple-precision floating-point
> > +library.  This library may be included with your operating system
> > +distribution; if it is not, you can get the latest version from
> > +@url{http://www.mpfr.org}.  At least version 3.1 of GNU MPFR is
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Same here.
> 
> > +formats than the host.  If GNU MPFR it is not available, GDB will
>                                                             ^^^
> @value{GDBN}
> 
> The changes are okay with those gotchas fixed.

OK, thanks for the review.  I've updated the patch below.

Thanks,
Ulrich


gdb/ChangeLog:

	* NEWS: Document use of GNU MPFR.
	* README: Likewise.
	* doc/gdb.texinfo: Likewise

Index: binutils-gdb/gdb/NEWS
===================================================================
--- binutils-gdb.orig/gdb/NEWS
+++ binutils-gdb/gdb/NEWS
@@ -3,6 +3,11 @@
 
 *** Changes since GDB 8.0
 
+* GDB now uses the GNU MPFR library, if available, to emulate target
+  floating-point arithmetic during expression evaluation when the target
+  uses different floating-point formats than the host.  At least version
+  3.1 of GNU MPFR is required.
+
 * GDB now supports access to the guarded-storage-control registers and the
   software-based guarded-storage broadcast control registers on IBM z14.
 
Index: binutils-gdb/gdb/README
===================================================================
--- binutils-gdb.orig/gdb/README
+++ binutils-gdb/gdb/README
@@ -89,6 +89,14 @@ features.  Expat will be linked in if it
 those features will be disabled.  The latest version of Expat should be
 available from `http://expat.sourceforge.net'.
 
+   GDB uses GNU MPFR, a library for multiple-precision floating-point
+computation with correct rounding, to emulate target floating-point
+arithmetic during expression evaluation when the target uses different
+floating-point formats than the host.  MPFR will be linked in if it is
+available at build time.  If GNU MPFR it is not available, GDB will fall
+back to using host floating-point arithmetic.  The latest version of
+GNU MPFR should be available from `http://www.mpfr.org'.
+
    GDB can be used as a cross-debugger, running on a machine of one
 type while debugging a program running on a machine of another type.
 See below.
@@ -475,6 +483,15 @@ prefer; but you may abbreviate option na
      have libexpat installed, you can  get the latest version from
      http://expat.sourceforge.net.
 
+`--with-mpfr'
+     Build GDB with the GNU MPFR library.  (Done by default if
+     GNU MPFR is installed and found at configure time.)  This library
+     is used to emulate target floating-point arithmetic during expression
+     evaluation when the target uses different floating-point formats than
+     the host.  If GNU MPFR is not available, GDB will fall back to using
+     host floating-point arithmetic.  If your host does not have GNU MPFR
+     installed, you can get the latest version from http://www.mpfr.org.
+
 `--with-python[=PATH]'
      Build GDB with Python scripting support.  (Done by default if
      libpython is present and found at configure time.)  Python makes
Index: binutils-gdb/gdb/doc/gdb.texinfo
===================================================================
--- binutils-gdb.orig/gdb/doc/gdb.texinfo
+++ binutils-gdb/gdb/doc/gdb.texinfo
@@ -34270,6 +34270,21 @@ Branch trace (@pxref{Branch Trace Format
 @pxref{Branch Trace Configuration Format})
 @end itemize
 
+@item MPFR
+@anchor{MPFR}
+@value{GDBN} can use the GNU MPFR multiple-precision floating-point
+library.  This library may be included with your operating system
+distribution; if it is not, you can get the latest version from
+@url{http://www.mpfr.org}.  The @file{configure} script will search
+for this library in several standard locations; if it is installed
+in an unusual path, you can use the @option{--with-libmpfr-prefix}
+option to specify its location.
+
+GNU MPFR is used to emulate target floating-point arithmetic during
+expression evaluation when the target uses different floating-point
+formats than the host.  If GNU MPFR it is not available, @value{GDBN}
+will fall back to using host floating-point arithmetic.
+
 @item zlib
 @cindex compressed debug sections 
 @value{GDBN} will use the @samp{zlib} library, if available, to read

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

Re: Doc update to mention MPFR (Re: [RFC][00/19] Target FP: Precise target floating-point emulation)

[Eli Zaretskii]

> Date: Mon, 20 Nov 2017 18:39:23 +0100 (CET)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> OK, thanks for the review.  I've updated the patch below.

The updated patch is fine, thanks.