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
+2020-01-26 Tom Tromey <tromey@adacore.com>
+
+ * gdb.texinfo (M68K Features): Document floating-point feature
+ correspondence.
+
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Attach): Document the new option and the
This feature is optional. If present, it should contain registers
@samp{fp0} through @samp{fp7}, @samp{fpcontrol}, @samp{fpstatus} and
@samp{fpiaddr}.
+
+Note that, despite the fact that this feature's name says
+@samp{coldfire}, it is used to describe any floating point registers.
+The size of the registers must match the main m68k flavor; so, for
+example, if the primary feature is reported as @samp{coldfire}, then
+64-bit floating point registers are required.
@end table
@node NDS32 Features