Re: [PATCH] Rename i386_xxx_reg_to_regnum

Brian Ford
2004-04-09T17:49:00Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 929 bytes --]

On Fri, 9 Apr 2004, Mark Kettenis wrote:

> On Wed, 7 Apr 2004, Jim Blandy wrote:
>> Brian Ford writes:
>>> Let me know if I need to generate a new patch with the two changes
>>> above. Call me lazy ;-).
>>
>> Well, it's up to Mark. I'm just making suggestions. :)
>
> I'll take it from here. I'm currently revising the way signal
> trampolines are handled for IA-32 and AMD64, which is pretty invasive.
> I'll rename things after I've sorted that out.

Ok, I see you have commited that now. I have attached a refreshed patch.
Everything merged cleanly. It includes the jimb -> ford change, but not
the svr4 -> svr4_dbx change. Same ChangeLog entry as before.

I hope it is usefull. Thanks.

PS. I have one Cygwin related patch to submit that pseudo depends on this
one.

--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444

[-- Attachment #2: Type: TEXT/PLAIN, Size: 7578 bytes --]

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.184
diff -u -p -r1.184 i386-tdep.c
--- i386-tdep.c 9 Apr 2004 16:28:50 -0000 1.184
+++ i386-tdep.c 9 Apr 2004 17:34:08 -0000
@@ -51,8 +51,7 @@
#include "i386-tdep.h"
#include "i387-tdep.h"

-/* Names of the registers. The first 10 registers match the register
- numbering scheme used by GCC for stabs and DWARF. */
+/* Register names by GDB cooked register number. */

static char *i386_register_names[] =
{
@@ -166,49 +165,13 @@ i386_register_name (int reg)
return NULL;
}

-
-/* FIXME: jimb/2004-04-01: I don't think these functions are right.
- For a given platform, GCC always uses the same register numbering
- in both STABS and Dwarf2: gcc/dbxout.c and gcc/dwarf2out.c both use
- the DBX_REGISTER_NUMBER macro, as defined by the config headers.
- If you compile a program so that its variables are allocated to
- floating-point registers, first with STABS and again with Dwarf 2,
- you'll see that the variable's register numbers are the same in
- each case.
-
- GCC does use (at least) two different register numberings on the
- i386; they differ in how they number %ebp, %esp, %eflags, and the
- floating-point registers. And it has a third numbering for "64bit
- mode", which I assume is x86_64. But it always uses a given
- numbering in both STABS and Dwarf.
-
- This does not match the arrangement we have below, which presumes
- that STABS and Dwarf numberings are different, and does some
- strange mixing and matching (e.g., registering the Dwarf 2 function
- as the STABS function for "Generic i386 ELF") to get close enough
- to the right effect on the platforms we care about.
-
- If we wanted to match GCC, we should have two separate register
- number translation functions (we handle x86_64 in a separate tdep
- file altogether), one corresponding to each of GCC's i386 register
- maps. And for a given platform, we would register one of them as
- both the STABS and Dwarf 2 functions.
-
- However, we don't aspire to match GCC; we aspire to match the
- native system's tools. I don't have access to lots of different
- native compilers and debuggers to verify that GCC is matching their
- behavior in this regard. Is it sufficient to argue that we at
- least want to match GNU's compiler, and say we'll fix bugs relative
- to native tools as they're reported? */
-
-
-/* Convert stabs register number REG to the appropriate register
- number used by GDB. */
+/* Convert a dbx style register number to the appropriate
+ GDB cooked register number. */

static int
-i386_stab_reg_to_regnum (int reg)
+i386_dbx_reg_to_regnum (int reg)
{
- /* This implements what GCC calls the "default" register map. */
+ /* This translates what GCC calls the dbx_register_map[]. */
if (reg >= 0 && reg <= 7)
{
/* General-purpose registers. The debug info calls %ebp
@@ -239,14 +202,15 @@ i386_stab_reg_to_regnum (int reg)
return NUM_REGS + NUM_PSEUDO_REGS;
}

-/* Convert DWARF register number REG to the appropriate register
- number used by GDB. */
+/* Convert a SVR4 style register number to the appropriate
+ GDB cooked register number. */

static int
-i386_dwarf_reg_to_regnum (int reg)
+i386_svr4_reg_to_regnum (int reg)
{
- /* The DWARF register numbering includes %eip and %eflags, and
- numbers the floating point registers differently. */
+ /* This translates what GCC calls the svr4_dbx_register_map[].
+ It includes %eip and %eflags, and numbers the floating-point
+ registers differently. */
if (reg >= 0 && reg <= 9)
{
/* General-purpose registers. */
@@ -259,8 +223,8 @@ i386_dwarf_reg_to_regnum (int reg)
}
else if (reg >= 21)
{
- /* The SSE and MMX registers have identical numbers as in stabs. */
- return i386_stab_reg_to_regnum (reg);
+ /* SSE and MMX registers have identical numbers in the dbx style map. */
+ return i386_dbx_reg_to_regnum (reg);
}

/* This will hopefully provoke a warning. */
@@ -1819,8 +1783,8 @@ i386_svr4_sigcontext_addr (struct frame_
void
i386_elf_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
{
- /* We typically use stabs-in-ELF with the DWARF register numbering. */
- set_gdbarch_stab_reg_to_regnum (gdbarch, i386_dwarf_reg_to_regnum);
+ /* We typically use stabs-in-ELF with the SVR4 style register numbering. */
+ set_gdbarch_stab_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
}

/* System V Release 4 (SVR4). */
@@ -2014,13 +1978,40 @@ i386_gdbarch_init (struct gdbarch_info i
set_gdbarch_ps_regnum (gdbarch, I386_EFLAGS_REGNUM); /* %eflags */
set_gdbarch_fp0_regnum (gdbarch, I386_ST0_REGNUM); /* %st(0) */

- /* Use the "default" register numbering scheme for stabs and COFF. */
- set_gdbarch_stab_reg_to_regnum (gdbarch, i386_stab_reg_to_regnum);
- set_gdbarch_sdb_reg_to_regnum (gdbarch, i386_stab_reg_to_regnum);
-
- /* Use the DWARF register numbering scheme for DWARF and DWARF 2. */
- set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_dwarf_reg_to_regnum);
- set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_dwarf_reg_to_regnum);
+/* FIXME: ford/2004-04-09: Currently, each GCC i386 target uses the
+ same register numbering scheme across all of its supported debugging
+ formats ie. sdb (COFF), stabs, and DWARF 2. gcc/ sdbout.c, dbxout.c,
+ and dwarf2out.c all use the DBX_REGISTER_NUMBER macro, which is defined
+ by each target's respective config header in a manner independant of
+ the requested output debugging format.
+
+ GCC does have two possible register numbering schemes on the i386:
+ dbx and SVR4. These schemes differ in how they number %ebp, %esp,
+ %eflags, and the floating-point registers. GCC also has a third
+ possible numbering scheme used exclusively in "64bit mode": dbx64,
+ which I assume corresponds to x86_64, for which we have a seperate
+ -tdep file.
+
+ This does not match the arrangement below, which presumes that the
+ sdb and stabs numbering schemes differ from the DWARF and DWARF 2
+ ones. i386_elf_init_abi exists only to correct this presumption.
+ If we wanted to match GCC, then for any given target, we would only
+ use one register number translation function across all its supported
+ debug formats. However, we don't aspire to match GCC, we aspire to
+ match the native system's tools. But, I don't have access to lots of
+ different native compilers and debuggers in order to verify that GCC
+ is matching their behavior in this regard.
+
+ Is it sufficient to argue that we at least want to match GNU's compiler,
+ and we'll fix bugs relative to the native tools as they're reported? */
+
+ /* Use the dbx style register numbering scheme for stabs and sdb (COFF). */
+ set_gdbarch_stab_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum);
+ set_gdbarch_sdb_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum);
+
+ /* Use the SVR4 style register numbering scheme for DWARF and DWARF 2. */
+ set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
+ set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);

/* We don't define ECOFF_REG_TO_REGNUM, since ECOFF doesn't seem to
be in use on any of the supported i386 targets. */