1 May 2002 01:37
[PATCH] rs6000-tdep.c: Add fpscr comment
Kevin Buettner <kevinb <at> redhat.com>
2002-04-30 23:37:51 GMT
2002-04-30 23:37:51 GMT
I've just committed the patch below.
* rs6000-tdep.c: Added comment describing how fpscr register
numbers were chosen.
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.62
diff -u -p -r1.62 rs6000-tdep.c
--- rs6000-tdep.c 30 Apr 2002 00:26:43 -0000 1.62
+++ rs6000-tdep.c 30 Apr 2002 23:34:38 -0000
<at> <at> -2026,7 +2026,21 <at> <at> rs6000_convert_from_func_ptr_addr (CORE_
Most of these register groups aren't anything formal. I arrived at
them by looking at the registers that occurred in more than one
- processor. */
+ processor.
+
+ Note: kevinb/2002-04-30: Support for the fpscr register was added
+ during April, 2002. Slot 70 is being used for PowerPC and slot 71
+ for Power. For PowerPC, slot 70 was unused and was already in the
+ PPC_UISA_SPRS which is ideally where fpscr should go. For Power,
+ slot 70 was being used for "mq", so the next available slot (71)
+ was chosen. It would have been nice to be able to make the
+ register numbers the same across processor cores, but this wasn't
+ possible without either 1) renumbering some registers for some
+ processors or 2) assigning fpscr to a really high slot that's
+ larger than any current register number. Doing (1) is bad because
+ existing stubs would break. Doing (2) is undesirable because it
(Continue reading)
Looking at libiberty, the value is entered into a global table. Should,
instead, gdb call into functions like cplus_demangle_opname() function
with an explicit cplus_marker[] table?
----
> + /* CPLUS_MARKER must be computed at runtime */
> + char vptr_name[] = { '_', 'v', 'p', 't', 'r', CPLUS_MARKER, '\0'};
> + char vb_name[] = {'_', 'v', 'b', CPLUS_MARKER, '\0'};
> + /* CPLUS_MARKER must be computed at runtime */
I'll wait a couple days for any objections to surface and then go
ahead and check it in if there aren't any.
-Fred
RSS Feed