This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
x86 DBX_REGISTER_NUMBER cleanup
- To: gcc-patches at gcc dot gnu dot org
- Subject: x86 DBX_REGISTER_NUMBER cleanup
- From: Richard Henderson <rth at cygnus dot com>
- Date: Sun, 23 Jan 2000 13:45:30 -0800
There were only about a dozen copies of the svr4 register map.
Also use an array to do the mapping instead of 7 branches.
r~
* 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.
Index: beos-elf.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/beos-elf.h,v
retrieving revision 1.1
diff -c -p -d -r1.1 beos-elf.h
*** beos-elf.h 2000/01/13 00:37:06 1.1
--- beos-elf.h 2000/01/23 21:17:36
*************** Boston, MA 02111-1307, USA. */
*** 48,120 ****
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))
/* Output assembler code to FILE to increment profiler label # LABELNO
for profiling a function entry. */
--- 48,55 ----
necessary when compiling PIC code. */
#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
#undef DBX_REGISTER_NUMBER
! #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. */
Index: freebsd-elf.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/freebsd-elf.h,v
retrieving revision 1.20
diff -c -p -d -r1.20 freebsd-elf.h
*** freebsd-elf.h 1999/11/23 06:17:32 1.20
--- freebsd-elf.h 2000/01/23 21:17:36
*************** Boston, MA 02111-1307, USA. */
*** 49,121 ****
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))
/* Tell final.c that we don't need a label passed to mcount. */
--- 49,56 ----
necessary when compiling PIC code. */
#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]
/* Tell final.c that we don't need a label passed to mcount. */
Index: i386.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.125
diff -c -p -d -r1.125 i386.c
*** i386.c 2000/01/20 00:05:32 1.125
--- i386.c 2000/01/23 21:17:37
*************** enum reg_class const regclass_map[FIRST_
*** 233,242 ****
FP_TOP_REG, FP_SECOND_REG, FLOAT_REGS, FLOAT_REGS,
FLOAT_REGS, FLOAT_REGS, FLOAT_REGS, FLOAT_REGS,
/* arg pointer */
! INDEX_REGS,
! /* flags, fpsr */
! NO_REGS, NO_REGS
};
/* Test and compare insns in i386.md store the information needed to
generate branch and scc insns here. */
--- 233,314 ----
FP_TOP_REG, FP_SECOND_REG, FLOAT_REGS, FLOAT_REGS,
FLOAT_REGS, FLOAT_REGS, FLOAT_REGS, FLOAT_REGS,
/* arg pointer */
! NON_Q_REGS,
! /* flags, fpsr, dirflag */
! NO_REGS, NO_REGS, NO_REGS
! };
!
! /* The "default" register map. */
!
! int const dbx_register_map[FIRST_PSEUDO_REGISTER] =
! {
! 0, 2, 1, 3, 6, 7, 4, 5, /* general regs */
! 12, 13, 14, 15, 16, 17, 18, 19, /* fp regs */
! -1, -1, -1, -1, /* arg, flags, fpsr, dir */
! };
!
! /* 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 (gcc regno = 0)
! 1 for %ecx (gcc regno = 2)
! 2 for %edx (gcc regno = 1)
! 3 for %ebx (gcc regno = 3)
! 4 for %esp (gcc regno = 7)
! 5 for %ebp (gcc regno = 6)
! 6 for %esi (gcc regno = 4)
! 7 for %edi (gcc 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 gcc equivalent)
! 9 for %eflags (gcc regno = 17)
! 10 for %trapno (no gcc 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) (gcc regno = 8)
! 12 for %st(1) (gcc regno = 9)
! 13 for %st(2) (gcc regno = 10)
! 14 for %st(3) (gcc regno = 11)
! 15 for %st(4) (gcc regno = 12)
! 16 for %st(5) (gcc regno = 13)
! 17 for %st(6) (gcc regno = 14)
! 18 for %st(7) (gcc regno = 15)
! */
! int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =
! {
! 0, 2, 1, 3, 6, 7, 5, 4, /* general regs */
! 11, 12, 13, 14, 15, 16, 17, 18, /* fp regs */
! -1, 9, -1, -1, /* arg, flags, fpsr, dir */
};
+
+
/* Test and compare insns in i386.md store the information needed to
generate branch and scc insns here. */
Index: i386.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386.h,v
retrieving revision 1.92
diff -c -p -d -r1.92 i386.h
*** i386.h 2000/01/20 00:05:32 1.92
--- i386.h 2000/01/23 21:17:37
*************** number as al, and ax.
*** 2185,2201 ****
/* How to renumber registers for dbx and gdb. */
! /* {0,2,1,3,6,7,4,5,12,13,14,15,16,17} */
! #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 ? 4 : \
! (n) == 7 ? 5 : \
! (n) + 4)
/* Before the prologue, RA is at 0(%esp). */
#define INCOMING_RETURN_ADDR_RTX \
--- 2185,2194 ----
/* How to renumber registers for dbx and gdb. */
! #define DBX_REGISTER_NUMBER(n) dbx_register_map[n]
!
! extern int const dbx_register_map[FIRST_PSEUDO_REGISTER];
! extern int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER];
/* Before the prologue, RA is at 0(%esp). */
#define INCOMING_RETURN_ADDR_RTX \
Index: i386elf.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/i386elf.h,v
retrieving revision 1.3
diff -c -p -d -r1.3 i386elf.h
*** i386elf.h 1999/10/01 17:02:21 1.3
--- i386elf.h 2000/01/23 21:17:37
*************** do { long value[3]; \
*** 115,196 ****
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
- /* 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 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
! #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))
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the
--- 115,122 ----
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the
Index: linux.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/linux.h,v
retrieving revision 1.16
diff -c -p -d -r1.16 linux.h
*** linux.h 1999/09/15 21:41:14 1.16
--- linux.h 2000/01/23 21:17:37
*************** Boston, MA 02111-1307, USA. */
*** 51,123 ****
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))
/* Output assembler code to FILE to increment profiler label # LABELNO
for profiling a function entry. */
--- 51,58 ----
necessary when compiling PIC code. */
#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
#undef DBX_REGISTER_NUMBER
! #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. */
Index: osfrose.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/osfrose.h,v
retrieving revision 1.9
diff -c -p -d -r1.9 osfrose.h
*** osfrose.h 1999/09/15 21:41:14 1.9
--- osfrose.h 2000/01/23 21:17:37
*************** while (0)
*** 877,910 ****
we want to retain compatibility with older gcc versions. */
#define DEFAULT_PCC_STRUCT_RETURN 0
! /* Map i386 registers to the numbers dwarf expects. Of course this is different
! from what stabs expects. */
!
! #define DWARF_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))
!
! /* Now what stabs expects in the register. */
! #define STABS_DBX_REGISTER_NUMBER(n) \
! ((n) == 0 ? 0 : \
! (n) == 1 ? 2 : \
! (n) == 2 ? 1 : \
! (n) == 3 ? 3 : \
! (n) == 4 ? 6 : \
! (n) == 5 ? 7 : \
! (n) == 6 ? 4 : \
! (n) == 7 ? 5 : \
! (n) + 4)
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) ((write_symbols == DWARF_DEBUG) \
! ? DWARF_DBX_REGISTER_NUMBER(n) \
! : STABS_DBX_REGISTER_NUMBER(n))
--- 877,886 ----
we want to retain compatibility with older gcc versions. */
#define DEFAULT_PCC_STRUCT_RETURN 0
! /* Map i386 registers to the numbers dwarf expects. Of course this is
! different from what stabs expects. */
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) ((write_symbols == DWARF_DEBUG) \
! ? svr4_dbx_register_map[n] \
! : dbx_register_map[n])
Index: ptx4-i.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/ptx4-i.h,v
retrieving revision 1.5
diff -c -p -d -r1.5 ptx4-i.h
*** ptx4-i.h 1998/12/16 21:03:55 1.5
--- ptx4-i.h 2000/01/23 21:17:37
*************** do { long value[3]; \
*** 107,188 ****
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
- /* 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))
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the
--- 107,114 ----
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the
Index: rtemself.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/rtemself.h,v
retrieving revision 1.5
diff -c -p -d -r1.5 rtemself.h
*** rtemself.h 2000/01/05 07:10:34 1.5
--- rtemself.h 2000/01/23 21:17:37
*************** Boston, MA 02111-1307, USA. */
*** 48,120 ****
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))
/* Output assembler code to FILE to increment profiler label # LABELNO
for profiling a function entry. */
--- 48,55 ----
necessary when compiling PIC code. */
#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic)
#undef DBX_REGISTER_NUMBER
! #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. */
Index: sco5.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/sco5.h,v
retrieving revision 1.33
diff -c -p -d -r1.33 sco5.h
*** sco5.h 2000/01/23 13:46:16 1.33
--- sco5.h 2000/01/23 21:17:37
*************** do { \
*** 541,568 ****
#define DBX_FUNCTION_FIRST 1
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) \
! ((TARGET_ELF) ? \
! ((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)) \
! : \
! ((n) == 0 ? 0 : \
! (n) == 1 ? 2 : \
! (n) == 2 ? 1 : \
! (n) == 3 ? 3 : \
! (n) == 4 ? 6 : \
! (n) == 5 ? 7 : \
! (n) == 6 ? 4 : \
! (n) == 7 ? 5 : \
! (n) + 4))
#undef DWARF_DEBUGGING_INFO
#undef SDB_DEBUGGING_INFO
--- 541,548 ----
#define DBX_FUNCTION_FIRST 1
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) \
! ((TARGET_ELF) ? svr4_dbx_register_map[n] : dbx_register_map[n])
#undef DWARF_DEBUGGING_INFO
#undef SDB_DEBUGGING_INFO
Index: sequent.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/sequent.h,v
retrieving revision 1.4
diff -c -p -d -r1.4 sequent.h
*** sequent.h 1999/01/19 20:33:04 1.4
--- sequent.h 2000/01/23 21:17:37
*************** Boston, MA 02111-1307, USA. */
*** 64,73 ****
* dbx order is ax, dx, cx, st(0), st(1), bx, si, di, st(2), st(3),
* st(4), st(5), st(6), st(7), sp, bp */
- /* ??? The right thing would be to change the ordering of the
- registers to correspond to the conventions of this system,
- and get rid of DBX_REGISTER_NUMBER. */
-
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) \
((n) < 3 ? (n) : (n) < 6 ? (n) + 2 \
--- 64,69 ----
Index: sysv4.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/sysv4.h,v
retrieving revision 1.6
diff -c -p -d -r1.6 sysv4.h
*** sysv4.h 1998/12/16 21:04:22 1.6
--- sysv4.h 2000/01/23 21:17:37
*************** do { long value[3]; \
*** 105,186 ****
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
- /* 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))
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the
--- 105,112 ----
fprintf (FILE, "\t.version\t\"01.01\"\n"); \
} while (0)
#undef DBX_REGISTER_NUMBER
! #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]
/* The routine used to output sequences of byte values. We use a special
version of this for most svr4 targets because doing so makes the