MatCat.OpenSource/8sa1-binutils-gdb
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

* rs6000-tdep.c: Added comment describing how fpscr register

Browse Source 
numbers were chosen.
This commit is contained in:
Kevin Buettner 2002-04-30 23:36:11 +00:00
parent aa67bccfe2
commit 6f5987a63d
2 changed files with 20 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/ChangeLog
View File

@ -1,3 +1,8 @@
2002-04-30 Kevin Buettner <kevinb@redhat.com>
* rs6000-tdep.c: Added comment describing how fpscr register
numbers were chosen.
2002-04-30 Michael Snyder <msnyder@redhat.com>
* gnu-nat.c (gnu_find_memory_regions): Fix merge botch.

16
gdb/rs6000-tdep.c
View File

@ -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. */