b7d2fe148e
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
|
||
|---|---|---|
| .. | ||
| .gitignore | ||
| a4rc.sed | ||
| agentexpr.texi | ||
| all-cfg.texi | ||
| annotate.texinfo | ||
| ChangeLog | ||
| doxy-index.in | ||
| Doxyfile-base.in | ||
| Doxyfile-gdb-api.in | ||
| Doxyfile-gdb-xref.in | ||
| Doxyfile-gdbserver.in | ||
| fdl.texi | ||
| filter-for-doxygen | ||
| filter-params.pl | ||
| gdb.texinfo | ||
| gpl.texi | ||
| guile.texi | ||
| lpsrc.sed | ||
| Makefile.in | ||
| psrc.sed | ||
| python.texi | ||
| refcard.tex | ||
| stabs.texinfo | ||
| stack_frame.eps | ||
| stack_frame.pdf | ||
| stack_frame.png | ||
| stack_frame.svg | ||
| stack_frame.txt | ||
