i386.c (dbx_register_map, [...]): New.

        * i386.c (dbx_register_map, svr4_dbx_register_map): New.
        * i386.h (DBX_REGISTER_NUMBER): Use them.
        * i386/beos-elf.h, i386/freebsd-elf.h, i386/i386elf.h: Likewise.
        * i386/linux.h, i386/osfrose.h, i386/ptx4-i.h: Likewise.
        * i386/rtemself.h, i386/sco5.h, i386/sysv4.h: Likewise.
        * i386/sequent.h: Kill incorrect comment.

From-SVN: r31575

1 files changed, 1 insertions, 66 deletions

diff --git a/gcc/config/i386/beos-elf.h b/gcc/config/i386/beos-elf.h
index 44524df..34d94f5 100644
--- a/gcc/config/i386/beos-elf.h
+++ b/gcc/config/i386/beos-elf.h
@@ -48,73 +48,8 @@ Boston, MA 02111-1307, USA.  */
    necessary when compiling PIC code.  */
 #define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
 
-/* Copy this from the svr4 specifications... */
-/* Define the register numbers to be used in Dwarf debugging information.
-   The SVR4 reference port C compiler uses the following register numbers
-   in its Dwarf output code:
-	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 compatibility with.
-   The version 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
-#define DBX_REGISTER_NUMBER(n) \
-((n) == 0 ? 0 \
- : (n) == 1 ? 2 \
- : (n) == 2 ? 1 \
- : (n) == 3 ? 3 \
- : (n) == 4 ? 6 \
- : (n) == 5 ? 7 \
- : (n) == 6 ? 5 \
- : (n) == 7 ? 4 \
- : ((n) >= FIRST_STACK_REG && (n) <= LAST_STACK_REG) ? (n)+3 \
- : (-1))
+#define DBX_REGISTER_NUMBER(n)  svr4_dbx_register_map[n]
 
 /* Output assembler code to FILE to increment profiler label # LABELNO
    for profiling a function entry.  */