aboutsummaryrefslogtreecommitdiff
path: root/libiberty/basename.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2019-10-24 10:30:13 -0600
committerTom Tromey <tromey@adacore.com>2020-01-26 14:46:27 -0700
commitb7d2fe148e7662875b9d64c0d1e25fa853d26b5e (patch)
tree327739e280a7554fc70901c0d9b87935633868d5 /libiberty/basename.c
parent65e5fdc0c17f41581bbfe34a936043c5ee3eeb93 (diff)
downloadgdb-b7d2fe148e7662875b9d64c0d1e25fa853d26b5e.zip
gdb-b7d2fe148e7662875b9d64c0d1e25fa853d26b5e.tar.gz
gdb-b7d2fe148e7662875b9d64c0d1e25fa853d26b5e.tar.bz2
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
Diffstat (limited to 'libiberty/basename.c')
0 files changed, 0 insertions, 0 deletions