OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source 
* 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
This commit is contained in:
Richard Henderson 2000-01-23 13:43:06 -08:00 committed by Richard Henderson
parent d416576b49
commit 837748497c
13 changed files with 102 additions and 558 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
gcc/ChangeLog
View File

@ -1,3 +1,12 @@
2000-01-23 Richard Henderson <rth@cygnus.com>
* 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 <mark@codesourcery.com>
* ggc-page.c (struct page_entry): Make `context_depth' an

67
gcc/config/i386/beos-elf.h
View File

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

67
gcc/config/i386/freebsd-elf.h
View File

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

78
gcc/config/i386/i386.c
View File

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

15
gcc/config/i386/i386.h
View File

@ -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 \

76
gcc/config/i386/i386elf.h
View File

@ -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

67
gcc/config/i386/linux.h
View File

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

32
gcc/config/i386/osfrose.h
View File

@ -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))
? svr4_dbx_register_map[n] \
: dbx_register_map[n])

76
gcc/config/i386/ptx4-i.h
View File

@ -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

67
gcc/config/i386/rtemself.h
View File

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

22
gcc/config/i386/sco5.h
View File

@ -542,27 +542,7 @@ do { \
#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))
((TARGET_ELF) ? svr4_dbx_register_map[n] : dbx_register_map[n])
#undef DWARF_DEBUGGING_INFO
#undef SDB_DEBUGGING_INFO

4
gcc/config/i386/sequent.h
View File

@ -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 \

76
gcc/config/i386/sysv4.h
View File

@ -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