]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Document m68k floating point feature correspondence
authorTom Tromey <tromey@adacore.com>
Thu, 24 Oct 2019 16:30:13 +0000 (10:30 -0600)
committerTom Tromey <tromey@adacore.com>
Sun, 26 Jan 2020 21:46:27 +0000 (14:46 -0700)
commitb7d2fe148e7662875b9d64c0d1e25fa853d26b5e
tree327739e280a7554fc70901c0d9b87935633868d5
parent65e5fdc0c17f41581bbfe34a936043c5ee3eeb93
Document m68k floating point feature correspondence

From what I can tell, The m68k floating point target feature should
apparently always be called "org.gnu.gdb.coldfire.fp" -- even when the
primary feature is not "coldfire", because m68k_gdbarch_init only
checks for this feature when assigning register numbers.

However, the floating point registers are expected to match what gdb
thinks are the register sizes for the primary feature.  For example,
if the main feature is "coldfire", then the floating point registers
should be 64 bits.

See this note for some an instance of this confusion:

    https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg04564.html

This patch documents the oddity.

Let me know what you think.  An alternate approach here might be to
make gdb adapt to the register sizes as actually reported.  I'm not
sure if this makes sense or not.

gdb/doc/ChangeLog
2020-01-26  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (M68K Features): Document floating-point feature
correspondence.

Change-Id: I4cd86acbe3449a29ce38327524c508c206b25b8f
gdb/doc/ChangeLog
gdb/doc/gdb.texinfo