From 2247c448dbdb2ea454cd484339a334ffd9772dad Mon Sep 17 00:00:00 2001 From: kevinb Date: Tue, 30 Apr 2002 23:36:11 +0000 Subject: [PATCH] * rs6000-tdep.c: Added comment describing how fpscr register numbers were chosen. --- gdb/ChangeLog | 5 +++++ gdb/rs6000-tdep.c | 16 +++++++++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 561090ea32..477225c500 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2002-04-30 Kevin Buettner + + * rs6000-tdep.c: Added comment describing how fpscr register + numbers were chosen. + 2002-04-30 Michael Snyder * gnu-nat.c (gnu_find_memory_regions): Fix merge botch. diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c index 72ceff024a..74285a3a4e 100644 --- a/gdb/rs6000-tdep.c +++ b/gdb/rs6000-tdep.c @@ -2026,7 +2026,21 @@ rs6000_convert_from_func_ptr_addr (CORE_ADDR addr) 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 + would introduce a really large gap between fpscr and the rest of + the registers for most processors. */ /* Convenience macros for populating register arrays. */ -- 2.11.0