Re: [PATCH] Proper _to_regnum for DWARF on cygwin (ping for Mark)

[Christopher Faylor <cgf at alum dot bu dot edu>]

I can approve the cygwin part of this patch but we Mark Kettenis to OK
the rest.

Mark does this look ok?  Who can approve the COFF stuff?

cgf


On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
>It would appear that DJGPP should do something similar, but I'll
>leave that up to Eli.
>
>2004-04-13  Brian Ford  <ford@vss.fsi.com>
>
>        * i386-tdep.c (i386_coff_init_abi): New function.
>        * i386-tdep.h (i386_coff_init_abi): New prototype.
>        * i386-cygwin-tdep.c (i386_cygwin_init_abi): Call it.  Use correct
>	register number translation functions for DWARF and DWARF 2.
>
>And, just in case you decide to approve the _to_regnum rename patch you
>requested :(, I have attached an updated/cumulative patch for that too.
>
>2004-04-13  Brian Ford  <ford@vss.fsi.com>
>
>        * i386-tdep.c: Correct register numbering scheme comments throughout.
>	(i386_stab_reg_to_regnum): Rename to i386_dbx_reg_to_regnum.
>	(i386_dwarf_reg_to_regnum): Rename to i386_svr4_reg_to_regnum.
>	(i386_elf_init_abi): Accomodate renames above.
>	(i386_gdb_arch_init): Likewise.
>        (i386_coff_init_abi): New function.
>        * i386-tdep.h (i386_coff_init_abi): New prototype.
>        * i386-cygwin-tdep.c (i386_cygwin_init_abi): Call it.  Use correct
>	register number translation functions for DWARF and DWARF 2.
>
>BTW, who am I waiting on to approve the coffread.c portion of this patch:
>
>http://sources.redhat.com/ml/gdb-patches/2004-04/msg00183.html
>
>Is it Philippe De Muyter?  A quick search of the archives shows the last
>message from him to be in June 2002.
>
>I'm not trying to be impatient.  I'd just like to know that the review is
>in *someone's* queue rather than lost in the ether.
>
>Thanks.
>
>-- 
>Brian Ford
>Senior Realtime Software Engineer
>VITAL - Visual Simulation Systems
>FlightSafety International
>Phone: 314-551-8460
>Fax:   314-551-8444
>Index: i386-tdep.c
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-tdep.c,v
>retrieving revision 1.185
>diff -u -p -r1.185 i386-tdep.c
>--- i386-tdep.c	9 Apr 2004 23:26:19 -0000	1.185
>+++ i386-tdep.c	13 Apr 2004 19:18:42 -0000
>@@ -1814,6 +1814,16 @@ i386_svr4_sigcontext_addr (struct frame_
> }
> 
> 
>+/* Generic COFF.  */
>+
>+void
>+i386_coff_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>+{
>+  /* We typically use DWARF-in-COFF with the stabs register numbering.  */
>+  set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_stab_reg_to_regnum);
>+  set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_stab_reg_to_regnum);
>+}
>+
> /* Generic ELF.  */
> 
> void
>Index: i386-tdep.h
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-tdep.h,v
>retrieving revision 1.38
>diff -u -p -r1.38 i386-tdep.h
>--- i386-tdep.h	9 Apr 2004 16:28:50 -0000	1.38
>+++ i386-tdep.h	13 Apr 2004 19:18:42 -0000
>@@ -210,6 +210,9 @@ extern const struct regset *
>   i386_regset_from_core_section (struct gdbarch *gdbarch,
> 				 const char *sect_name, size_t sect_size);
> 
>+/* Initialize a basic COFF architecture variant.  */
>+extern void i386_coff_init_abi (struct gdbarch_info, struct gdbarch *);
>+
> /* Initialize a basic ELF architecture variant.  */
> extern void i386_elf_init_abi (struct gdbarch_info, struct gdbarch *);
> 
>Index: i386-cygwin-tdep.c
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-cygwin-tdep.c,v
>retrieving revision 1.3
>diff -u -p -r1.3 i386-cygwin-tdep.c
>--- i386-cygwin-tdep.c	30 May 2003 19:24:29 -0000	1.3
>+++ i386-cygwin-tdep.c	13 Apr 2004 19:18:41 -0000
>@@ -31,6 +31,8 @@ i386_cygwin_init_abi (struct gdbarch_inf
> {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> 
>+  i386_coff_init_abi (info, gdbarch);
>+
>   tdep->struct_return = reg_struct_return;
> }
> 

>Index: i386-tdep.c
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-tdep.c,v
>retrieving revision 1.185
>diff -u -p -r1.185 i386-tdep.c
>--- i386-tdep.c	9 Apr 2004 23:26:19 -0000	1.185
>+++ i386-tdep.c	13 Apr 2004 19:23:17 -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.  */
>@@ -1814,13 +1778,23 @@ i386_svr4_sigcontext_addr (struct frame_
> }
> 
> 
>+/* Generic COFF.  */
>+
>+void
>+i386_coff_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>+{
>+  /* We typically use DWARF-in-COFF with the dbx style register numbering.  */
>+  set_gdbarch_dwarf_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum);
>+  set_gdbarch_dwarf2_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum);
>+}
>+
> /* Generic ELF.  */
> 
> 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 +1988,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_[coff|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.  */
>Index: i386-tdep.h
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-tdep.h,v
>retrieving revision 1.38
>diff -u -p -r1.38 i386-tdep.h
>--- i386-tdep.h	9 Apr 2004 16:28:50 -0000	1.38
>+++ i386-tdep.h	13 Apr 2004 19:23:18 -0000
>@@ -210,6 +210,9 @@ extern const struct regset *
>   i386_regset_from_core_section (struct gdbarch *gdbarch,
> 				 const char *sect_name, size_t sect_size);
> 
>+/* Initialize a basic COFF architecture variant.  */
>+extern void i386_coff_init_abi (struct gdbarch_info, struct gdbarch *);
>+
> /* Initialize a basic ELF architecture variant.  */
> extern void i386_elf_init_abi (struct gdbarch_info, struct gdbarch *);
> 
>Index: i386-cygwin-tdep.c
>===================================================================
>RCS file: /cvs/src/src/gdb/i386-cygwin-tdep.c,v
>retrieving revision 1.3
>diff -u -p -r1.3 i386-cygwin-tdep.c
>--- i386-cygwin-tdep.c	30 May 2003 19:24:29 -0000	1.3
>+++ i386-cygwin-tdep.c	13 Apr 2004 19:23:15 -0000
>@@ -31,6 +31,8 @@ i386_cygwin_init_abi (struct gdbarch_inf
> {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> 
>+  i386_coff_init_abi (info, gdbarch);
>+
>   tdep->struct_return = reg_struct_return;
> }
>