i386.c (dbx_register_map, [...]): New.
* i386.c (dbx_register_map, svr4_dbx_register_map): New. * i386.h (DBX_REGISTER_NUMBER): Use them. * i386/beos-elf.h, i386/freebsd-elf.h, i386/i386elf.h: Likewise. * i386/linux.h, i386/osfrose.h, i386/ptx4-i.h: Likewise. * i386/rtemself.h, i386/sco5.h, i386/sysv4.h: Likewise. * i386/sequent.h: Kill incorrect comment. From-SVN: r31575
This commit is contained in:
parent
d416576b49
commit
837748497c
@ -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
|
||||
|
@ -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. */
|
||||
|
@ -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. */
|
||||
|
||||
|
@ -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. */
|
||||
|
||||
|
@ -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 \
|
||||
|
@ -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
|
||||
|
@ -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. */
|
||||
|
@ -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])
|
||||
|
@ -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
|
||||
|
@ -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. */
|
||||
|
@ -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
|
||||
|
@ -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 \
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user