*** empty log message ***

From-SVN: r1020

gcc/config/i386/sysv4.h

@@ -71,23 +71,64 @@ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
    The SVR4 reference port C compiler uses the following register numbers
    in its Dwarf output code:
 
-	0 for %eax (regno = 0)
-	1 for %ecx (regno = 2)
-	2 for %edx (regno = 1)
-	3 for %ebx (regno = 3)
-	4 for %esp (regno = 7)
-	5 for %ebp (regno = 6)
-	6 for %esi (regno = 4)
-	7 for %edi (regno = 5)
-
-	8  for FP_REGS[tos]   (regno = 8)
-	9  for FP_REGS[tos-1] (regno = 9)
-	10 for FP_REGS[tos-2] (regno = 10)
-	11 for FP_REGS[tos-3] (regno = 11)
-	12 for FP_REGS[tos-4] (regno = 12)
-	13 for FP_REGS[tos-5] (regno = 13)
-	14 for FP_REGS[tos-6] (regno = 14)
-	15 for FP_REGS[tos-7] (regno = 15)
+	0 for %eax (gnu regno = 0)
+	1 for %ecx (gnu regno = 2)
+	2 for %edx (gnu regno = 1)
+	3 for %ebx (gnu regno = 3)
+	4 for %esp (gnu regno = 7)
+	5 for %ebp (gnu regno = 6)
+	6 for %esi (gnu regno = 4)
+	7 for %edi (gnu regno = 5)
+
+   The following three DWARF register numbers are never generated by
+   the SVR4 C compiler or by the GNU compilers, but SDB on x86/svr4
+   believes these numbers have these meanings.
+
+	8  for %eip    (no gnu equivalent)
+	9  for %eflags (no gnu equivalent)
+	10 for %trapno (no gnu equivalent)
+
+   It is not at all clear how we should number the FP stack registers
+   for the x86 architecture.  If the version of SDB on x86/svr4 were
+   a bit less brain dead with respect to floating-point then we would
+   have a precedent to follow with respect to DWARF register numbers
+   for x86 FP registers, but the SDB on x86/svr4 is so completely
+   broken with respect to FP registers that it is hardly worth thinking
+   of it as something to strive for compatability with.
+
+   The verison of x86/svr4 SDB I have at the moment does (partially)
+   seem to believe that DWARF register number 11 is associated with
+   the x86 register %st(0), but that's about all.  Higher DWARF
+   register numbers don't seem to be associated with anything in
+   particular, and even for DWARF regno 11, SDB only seems to under-
+   stand that it should say that a variable lives in %st(0) (when
+   asked via an `=' command) if we said it was in DWARF regno 11,
+   but SDB still prints garbage when asked for the value of the
+   variable in question (via a `/' command).
+
+   (Also note that the labels SDB prints for various FP stack regs
+   when doing an `x' command are all wrong.)
+
+   Note that these problems generally don't affect the native SVR4
+   C compiler because it doesn't allow the use of -O with -g and
+   because when it is *not* optimizing, it allocates a memory
+   location for each floating-point variable, and the memory
+   location is what gets described in the DWARF AT_location
+   attribute for the variable in question.
+
+   Regardless of the severe mental illness of the x86/svr4 SDB, we
+   do something sensible here and we use the following DWARF
+   register numbers.  Note that these are all stack-top-relative
+   numbers.
+
+	11 for %st(0) (gnu regno = 8)
+	12 for %st(1) (gnu regno = 9)
+	13 for %st(2) (gnu regno = 10)
+	14 for %st(3) (gnu regno = 11)
+	15 for %st(4) (gnu regno = 12)
+	16 for %st(5) (gnu regno = 13)
+	17 for %st(6) (gnu regno = 14)
+	18 for %st(7) (gnu regno = 15)
 */
 
 #undef DBX_REGISTER_NUMBER
@@ -100,7 +141,7 @@ the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
  : (n) == 5 ? 7 \
  : (n) == 6 ? 5 \
  : (n) == 7 ? 4 \
- : ((n) >= FIRST_STACK_REG && (n) <= LAST_STACK_REG) ? (n) \
+ : ((n) >= FIRST_STACK_REG && (n) <= LAST_STACK_REG) ? (n)+3 \
  : (abort (), 0))
 
 /* The routine used to output sequences of byte values.  We use a special