From eb26ca2cc0119b1a2f16bba68c4f231e52d519ca Mon Sep 17 00:00:00 2001 From: rth Date: Sun, 23 Jan 2000 21:43:06 +0000 Subject: [PATCH] * 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. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@31575 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 9 +++++ gcc/config/i386/beos-elf.h | 67 +------------------------------------ gcc/config/i386/freebsd-elf.h | 67 +------------------------------------ gcc/config/i386/i386.c | 78 +++++++++++++++++++++++++++++++++++++++++-- gcc/config/i386/i386.h | 15 +++------ gcc/config/i386/i386elf.h | 76 +---------------------------------------- gcc/config/i386/linux.h | 67 +------------------------------------ gcc/config/i386/osfrose.h | 34 +++---------------- gcc/config/i386/ptx4-i.h | 76 +---------------------------------------- gcc/config/i386/rtemself.h | 67 +------------------------------------ gcc/config/i386/sco5.h | 24 ++----------- gcc/config/i386/sequent.h | 4 --- gcc/config/i386/sysv4.h | 76 +---------------------------------------- 13 files changed, 102 insertions(+), 558 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 72824f8..fc63569 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,12 @@ +2000-01-23 Richard Henderson + + * 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. + 2000-01-23 Mark Mitchell * ggc-page.c (struct page_entry): Make `context_depth' an 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. */ diff --git a/gcc/config/i386/freebsd-elf.h b/gcc/config/i386/freebsd-elf.h index 4c27dfa..360f844 100644 --- a/gcc/config/i386/freebsd-elf.h +++ b/gcc/config/i386/freebsd-elf.h @@ -49,73 +49,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] /* Tell final.c that we don't need a label passed to mcount. */ diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index ccb439f..c002262 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -233,11 +233,83 @@ enum reg_class const regclass_map[FIRST_PSEUDO_REGISTER] = 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 + 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. */ diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index f7d08bb..859b460 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -2185,17 +2185,10 @@ number as al, and ax. /* 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) +#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 \ diff --git a/gcc/config/i386/i386elf.h b/gcc/config/i386/i386elf.h index c94a0a99..2e75310 100644 --- a/gcc/config/i386/i386elf.h +++ b/gcc/config/i386/i386elf.h @@ -115,82 +115,8 @@ do { long value[3]; \ 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)) +#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 diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h index d208d29..9ba64c6 100644 --- a/gcc/config/i386/linux.h +++ b/gcc/config/i386/linux.h @@ -51,73 +51,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. */ diff --git a/gcc/config/i386/osfrose.h b/gcc/config/i386/osfrose.h index fbe8d31..1a2eee5 100644 --- a/gcc/config/i386/osfrose.h +++ b/gcc/config/i386/osfrose.h @@ -877,34 +877,10 @@ while (0) 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) +/* 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) \ - ? DWARF_DBX_REGISTER_NUMBER(n) \ - : STABS_DBX_REGISTER_NUMBER(n)) +#define DBX_REGISTER_NUMBER(n) ((write_symbols == DWARF_DEBUG) \ + ? svr4_dbx_register_map[n] \ + : dbx_register_map[n]) diff --git a/gcc/config/i386/ptx4-i.h b/gcc/config/i386/ptx4-i.h index 1537b4a..0303014 100644 --- a/gcc/config/i386/ptx4-i.h +++ b/gcc/config/i386/ptx4-i.h @@ -107,82 +107,8 @@ do { long value[3]; \ 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)) +#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 diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h index de8a5b7..c1c125f 100644 --- a/gcc/config/i386/rtemself.h +++ b/gcc/config/i386/rtemself.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. */ diff --git a/gcc/config/i386/sco5.h b/gcc/config/i386/sco5.h index 8980ec9..7fd7e00 100644 --- a/gcc/config/i386/sco5.h +++ b/gcc/config/i386/sco5.h @@ -541,28 +541,8 @@ do { \ #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)) +#define DBX_REGISTER_NUMBER(n) \ + ((TARGET_ELF) ? svr4_dbx_register_map[n] : dbx_register_map[n]) #undef DWARF_DEBUGGING_INFO #undef SDB_DEBUGGING_INFO diff --git a/gcc/config/i386/sequent.h b/gcc/config/i386/sequent.h index 8613ad7..daf62c4 100644 --- a/gcc/config/i386/sequent.h +++ b/gcc/config/i386/sequent.h @@ -64,10 +64,6 @@ Boston, MA 02111-1307, USA. */ * 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 \ diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h index e688f7b..0c16d2e 100644 --- a/gcc/config/i386/sysv4.h +++ b/gcc/config/i386/sysv4.h @@ -105,82 +105,8 @@ do { long value[3]; \ 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)) +#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 -- 2.7.4