[PATCH] Proper _to_regnum for DWARF on Cygwin

[PATCH] Proper _to_regnum for DWARF on Cygwin

[Brian Ford]

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

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

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

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_
 }
 \f
 
+/* 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;
 }
 

[-- Attachment #3: Type: TEXT/PLAIN, Size: 9200 bytes --]

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_
 }
 \f
 
+/* 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;
 }
 

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

[Christopher Faylor]

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_
> }
> \f
> 
>+/* 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_
> }
> \f
> 
>+/* 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;
> }
> 

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

[Brian Ford]

On Fri, 16 Apr 2004, Christopher Faylor wrote:

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

Yeah, I know.  Thanks for the partial.

> Who can approve the COFF stuff?
>
> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
> >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.

At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
give him a week or so to respond.

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

I'm still trying to be patient, but it's hard because I'm really excited
about finally getting DWARF 2 working on Cygwin.  It's been a year
and a half or more of *very* off and on work :-D (mostly off, ha, ha).

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

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Mark Kettenis]

   Date: Tue, 13 Apr 2004 15:12:42 -0500 (CDT)
   From: Brian Ford <ford@vss.fsi.com>

   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.

I've checked this one in now.  Can you easily regenerate the rename
patch now?  If so, feel free to mail it to me.  Otherwise I'll
probably do it myself later this weekend.

Mark

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Brian Ford]

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

On Fri, 16 Apr 2004, Mark Kettenis wrote:

> On Tue, 13 Apr 2004, Brian Ford wrote:
>
>> 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.
>
> I've checked this one in now.

Thanks!

> Can you easily regenerate the rename patch now?  If so, feel free to
> mail it to me.  Otherwise I'll probably do it myself later this weekend.

Sure.

2004-04-16  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_coff_init_abi, i386_elf_init_abi): Accomodate renames above.
        (i386_gdb_arch_init): Likewise.

-- 
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: 8210 bytes --]

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.186
diff -u -p -r1.186 i386-tdep.c
--- i386-tdep.c	16 Apr 2004 16:49:55 -0000	1.186
+++ i386-tdep.c	16 Apr 2004 17:21:59 -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,9 +1783,9 @@ i386_svr4_sigcontext_addr (struct frame_
 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);
+  /* 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.  */
@@ -1829,8 +1793,8 @@ i386_coff_init_abi (struct gdbarch_info 
 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).  */
@@ -2024,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.  */

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

[Christopher Faylor]

On Fri, Apr 16, 2004 at 11:26:57AM -0500, Brian Ford wrote:
>I'm still trying to be patient, but it's hard because I'm really excited
>about finally getting DWARF 2 working on Cygwin.  It's been a year
>and a half or more of *very* off and on work :-D (mostly off, ha, ha).

I'm pretty excited too.  I'm looking forward to actually being able to
debug the cygwin DLL without having to infer stack frames from:

    x/80x $esp

cgf

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Mark Kettenis]

The attached is what I actually checked in.  I changed some of the
comments to better reflect my own view on the matter.

Thanks anyway,

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
 
	Based on a patch from 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_coff_init_abi, i386_elf_init_abi): Accomodate renames above.
	(i386_gdb_arch_init): Likewise.

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.186
diff -u -p -r1.186 i386-tdep.c
--- i386-tdep.c 16 Apr 2004 16:49:55 -0000 1.186
+++ i386-tdep.c 18 Apr 2004 18:33:06 -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.  */
 
 static char *i386_register_names[] =
 {
@@ -71,7 +70,7 @@ static char *i386_register_names[] =
 
 static const int i386_num_register_names = ARRAY_SIZE (i386_register_names);
 
-/* MMX registers.  */
+/* Register names for MMX pseudo-registers.  */
 
 static char *i386_mmx_names[] =
 {
@@ -166,49 +165,15 @@ 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
+/* Convert a dbx register number REG to the appropriate register
    number used by GDB.  */
 
 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 implements what GCC calls the "default" register map
+     (dbx_register_map[]).  */
+
   if (reg >= 0 && reg <= 7)
     {
       /* General-purpose registers.  The debug info calls %ebp
@@ -239,13 +204,16 @@ 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 SVR4 register number REG to the appropriate register number
+   used by GDB.  */
 
 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
+  /* This implements the GCC register map that tries to be compatible
+     with the SVR4 C compiler for DWARF (svr4_dbx_register_map[]).  */
+
+  /* The SVR4 register numbering includes %eip and %eflags, and
      numbers the floating point registers differently.  */
   if (reg >= 0 && reg <= 9)
     {
@@ -259,8 +227,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);
+      /* The SSE and MMX registers have the same numbers as with dbx.  */
+      return i386_dbx_reg_to_regnum (reg);
     }
 
   /* This will hopefully provoke a warning.  */
@@ -1819,9 +1787,9 @@ i386_svr4_sigcontext_addr (struct frame_
 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);
+  /* We typically use DWARF-in-COFF with the dbx 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.  */
@@ -1829,8 +1797,8 @@ i386_coff_init_abi (struct gdbarch_info 
 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 register numbering.  */
+  set_gdbarch_stab_reg_to_regnum (gdbarch, i386_svr4_reg_to_regnum);
 }
 
 /* System V Release 4 (SVR4).  */
@@ -2024,13 +1992,43 @@ 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);
+  /* NOTE: kettenis/20040418: 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, and are implemented by the attays
+     dbx_register_map[] and svr4_dbx_register_map in
+     gcc/config/i386.c.  GCC also defines a third numbering scheme in
+     gcc/config/i386.c, which it designates as the "default" register
+     map used in 64bit mode.  This last register numbering scheme is
+     implemented in dbx64_register_map, and us used for AMD64; see
+     amd64-tdep.c.
+
+     Currently, each GCC i386 target always uses the same register
+     numbering scheme across all its supported debugging formats
+     i.e. SDB (COFF), stabs and DWARF 2.  This is because
+     gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the
+     DBX_REGISTER_NUMBER macro which is defined by each target's
+     respective config header in a manner independent of the requested
+     output debugging format.
+
+     This does not match the arrangement below, which presumes that
+     the SDB and stabs numbering schemes differ from the DWARF and
+     DWARF 2 ones.  The reason for this arrangement is that it is
+     likely to get the numbering scheme for the target's
+     default/native debug format right.  For targets where GCC is the
+     native compiler (FreeBSD, NetBSD, OpenBSD, GNU/Linux) or for
+     targets where the native toolchain uses a different numbering
+     scheme for a particular debug format (stabs-in-ELF on Solaris)
+     the defaults below will have to be overridden, like the functions
+     i386_coff_init_abi() and i386_elf_init_abi() do.  */
+
+  /* Use the dbx register numbering scheme for stabs and 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 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.  */

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Eli Zaretskii]

> Date: Sun, 18 Apr 2004 20:38:38 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> +  /* We typically use DWARF-in-COFF with the dbx 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);
>  }

Mark, doesn't this code above from i386_coff_init_abi contradict the
code further down (and the register mapping used by GCC), viz:

> +  /* Use the SVR4 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);

?  For DJGPP, at least, DWARF2-in-COFF uses i386_svr4_reg_to_regnum
register mapping, not i386_dbx_reg_to_regnum.  Am I missing something
here?

> +  /* NOTE: kettenis/20040418: 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, and are implemented by the attays
                                                             ^^^^^^
A typo.

> +     Currently, each GCC i386 target always uses the same register
> +     numbering scheme across all its supported debugging formats
> +     i.e. SDB (COFF), stabs and DWARF 2.  This is because
> +     gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the
> +     DBX_REGISTER_NUMBER macro which is defined by each target's
> +     respective config header in a manner independent of the requested
> +     output debugging format.

As the following fragment (already posted here yesterday) from
gcc/config/i386/djgpp.h shows, both of these assertions are not true
for the DJGPP target:

    #undef DBX_REGISTER_NUMBER
    #define DBX_REGISTER_NUMBER(n) \
      ((write_symbols == DWARF2_DEBUG) ? svr4_dbx_register_map[n] : dbx_register_map[n])

Also, in this old message:

    http://sources.redhat.com/ml/gdb/2001-07/msg00398.html

you pointed out to me that:

    Several GCC targets redefine DBX_REGISTER_NUMBER, see for example
    linux.h in that same directory [gcc/config/i386/].

So gcc/*out.c files are clearly not the whole story here (unless
things have changed in GCC since then; I cannot check this easily
where I'm typing this).

The upshot of all this is that either (a) I'm still confused by the
issues involved, or (b) the comments and, possibly, the code need to
be amended to clarify/fix that.

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Brian Ford]

On Mon, 19 Apr 2004, Eli Zaretskii wrote:

> On Sun, 18 Apr 2004 20:38:38 +0200 (CEST) Mark Kettenis wrote:
>
>> +  /* We typically use DWARF-in-COFF with the dbx 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);
>
> Mark, doesn't this code above from i386_coff_init_abi contradict the
> code further down (and the register mapping used by GCC), viz:

It does contradict the code further down by design, but not the proposed
DWARF register numbering for Cygwin, which is currently the only target to
call this function.  When this patch was written, it was assumed based on
the vanilla FSF GCC sources, that DJGPP would need the same functionality.
Thus the generic function name, but now we know better.

I'm seriously considering reverting that change.  I believe my original
gut feeling was correct before Jim Blandy convinced me otherwise.
Comments before I post the patch to do so?

> > +  /* Use the SVR4 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);
>
> ?  For DJGPP, at least, DWARF2-in-COFF uses i386_svr4_reg_to_regnum
> register mapping, not i386_dbx_reg_to_regnum.  Am I missing something
> here?

Nope, we were missing the DJGPP specific GCC patch you listed below.
Don't worry, nothing has been broken regardless.

[snip typo comment]
> > +     Currently, each GCC i386 target always uses the same register
> > +     numbering scheme across all its supported debugging formats
> > +     i.e. SDB (COFF), stabs and DWARF 2.  This is because
> > +     gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the
> > +     DBX_REGISTER_NUMBER macro which is defined by each target's
> > +     respective config header in a manner independent of the requested
> > +     output debugging format.
>
> As the following fragment (already posted here yesterday) from
> gcc/config/i386/djgpp.h shows, both of these assertions are not true
> for the DJGPP target:
>
>     #undef DBX_REGISTER_NUMBER
>     #define DBX_REGISTER_NUMBER(n) \
>       ((write_symbols == DWARF2_DEBUG) ? svr4_dbx_register_map[n] : dbx_register_map[n])

But we had no way of knowing that ;-).

> Also, in this old message:
>
>     http://sources.redhat.com/ml/gdb/2001-07/msg00398.html
>
> you pointed out to me that:
>
>     Several GCC targets redefine DBX_REGISTER_NUMBER, see for example
>     linux.h in that same directory [gcc/config/i386/].

Yes, but they all follow:

> > +     DBX_REGISTER_NUMBER macro which is defined by each target's
> > +     respective config header in a manner independent of the requested
> > +     output debugging format.
>
> So gcc/*out.c files are clearly not the whole story here (unless
> things have changed in GCC since then; I cannot check this easily
> where I'm typing this).

True.  They are not the *whole* story, but it was assumed that examining
all those config files mentioned above was the *relevant* part of the
story.

> The upshot of all this is that either (a) I'm still confused by the
> issues involved, or (b) the comments and, possibly, the code need to
> be amended to clarify/fix that.

a, the comment part of b, and I'm now convinced the code part of b should
be reverted for Cygwin.  I'll post a patch soon.

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

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Mark Kettenis]

   Date: 19 Apr 2004 08:50:59 +0200
   From: Eli Zaretskii <eliz@elta.co.il>

   > Date: Sun, 18 Apr 2004 20:38:38 +0200 (CEST)
   > From: Mark Kettenis <kettenis@chello.nl>
   > 
   > +  /* We typically use DWARF-in-COFF with the dbx 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);
   >  }

   Mark, doesn't this code above from i386_coff_init_abi contradict the
   code further down (and the register mapping used by GCC), viz:

   > +  /* Use the SVR4 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);

   ?  For DJGPP, at least, DWARF2-in-COFF uses i386_svr4_reg_to_regnum
   register mapping, not i386_dbx_reg_to_regnum.  Am I missing something
   here?

Hmm.  I very much agree with what Brian wrote in his follow-up
messages.  I think DJGPP is doing the right thing using the SVR4
scheme for DWARF2 while staying backwards compatible for stabs.  I'd
advise him to do the same for cygwin.  If i386_coff_init_abi will be
gone, the comments aren't contradictiory anymore.

   > +  /* NOTE: kettenis/20040418: 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, and are implemented by the attays
								^^^^^^
   A typo.

I though I'd fixed that one :-(.

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> I'm seriously considering reverting that change.  I believe my original
> gut feeling was correct before Jim Blandy convinced me otherwise.
> Comments before I post the patch to do so?

Well, my argument is weaker now that we know DJGPP uses different
numberings.  I was simply saying that GCC, for a specific target,
almost always uses the same register numbering in both STABS and Dwarf
2.  So I viewed the fact that Dwarf 2 always uses the svr4 numbering
as a mere consequence of other conditions:
- Dwarf 2 has only been widely used on ELF-based systems, and
- ELF systems, unsurprisingly, use the svr4 numbering.

But now that we know DJGPP actually does use different numberings
depending on the debug format, that's a genuine conflicting
precedent.  So I can see going either way.

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Brian Ford]

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

On Mon, 19 Apr 2004, Mark Kettenis wrote:

> Hmm.  I very much agree with what Brian wrote in his follow-up
> messages.  I think DJGPP is doing the right thing using the SVR4
> scheme for DWARF2 while staying backwards compatible for stabs.  I'd
> advise him to do the same for cygwin.

Ok, do I need approval to revert my own patch ;-) ?

2004-04-19  Brian Ford  <ford@vss.fsi.com>

	Revert 2004-04-16 change.
	* i386-tdep.c (i386_gdbarch_init): Fix comment typos.
	(i386_coff_init_abi): Remove.
	* i386-tdep.h (i386_coff_init_abi): Remove.
	* i386-cygwin-tdep.c (i386_cygwin_init_abi): Remove call to above.

> If i386_coff_init_abi will be gone, the comments aren't contradictiory
> anymore.

Not exactly, as Eli pointed out before, both of the following will be
false for DJGPP and Cygwin/Mingw:

     Currently, each GCC i386 target always uses the same register
     numbering scheme across all its supported debugging formats
     i.e. SDB (COFF), stabs and DWARF 2.  This is because
     gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the
     DBX_REGISTER_NUMBER macro which is defined by each target's
     respective config header in a manner independent of the requested
     output debugging format.

> On Mon, 19 Apr 2004 at 08:50:59 +0200, Eli Zaretskii wrote:
>
>> On Sun, 18 Apr 2004 20:38:38 +0200 (CEST), Mark Kettenis wrote:
>>
>>>+     floating-point registers, and are implemented by the attays
>> 							      ^^^^^^
>> A typo.
>
> I though I'd fixed that one :-(.

and another:

     implemented in dbx64_register_map, and us used for AMD64; see
                                            ^^

both of which are fixed in the attached patch.  Ok to apply?

-- 
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: 2861 bytes --]

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.187
diff -u -p -r1.187 i386-tdep.c
--- i386-tdep.c	18 Apr 2004 18:38:04 -0000	1.187
+++ i386-tdep.c	19 Apr 2004 23:34:07 -0000
@@ -1782,16 +1782,6 @@ i386_svr4_sigcontext_addr (struct frame_
 }
 \f
 
-/* Generic COFF.  */
-
-void
-i386_coff_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
-{
-  /* We typically use DWARF-in-COFF with the dbx 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
@@ -1995,12 +1985,12 @@ i386_gdbarch_init (struct gdbarch_info i
   /* NOTE: kettenis/20040418: 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, and are implemented by the attays
+     floating-point registers, and are implemented by the arrays
      dbx_register_map[] and svr4_dbx_register_map in
      gcc/config/i386.c.  GCC also defines a third numbering scheme in
      gcc/config/i386.c, which it designates as the "default" register
      map used in 64bit mode.  This last register numbering scheme is
-     implemented in dbx64_register_map, and us used for AMD64; see
+     implemented in dbx64_register_map, and is used for AMD64; see
      amd64-tdep.c.
 
      Currently, each GCC i386 target always uses the same register
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.39
diff -u -p -r1.39 i386-tdep.h
--- i386-tdep.h	16 Apr 2004 16:49:55 -0000	1.39
+++ i386-tdep.h	19 Apr 2004 23:34:07 -0000
@@ -210,9 +210,6 @@ 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.4
diff -u -p -r1.4 i386-cygwin-tdep.c
--- i386-cygwin-tdep.c	16 Apr 2004 16:49:55 -0000	1.4
+++ i386-cygwin-tdep.c	19 Apr 2004 23:34:07 -0000
@@ -31,8 +31,6 @@ 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;
 }
 

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Eli Zaretskii]

> Date: Mon, 19 Apr 2004 11:21:35 -0500 (CDT)
> From: Brian Ford <ford@vss.fsi.com>
> 
> I'm seriously considering reverting that change.  I believe my original
> gut feeling was correct before Jim Blandy convinced me otherwise.
> Comments before I post the patch to do so?

FWIW, I tend to agree that Cygwin should use the same register
numbering as almost all the other i386 targets.

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Brian Ford]

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

Oops, missed the comment refering to the removed function.  Updated patch
attached.  ChangeLog unchanged from below.  Ok to apply?

On Mon, 19 Apr 2004, Brian Ford wrote:

> On Mon, 19 Apr 2004, Mark Kettenis wrote:
>
> > Hmm.  I very much agree with what Brian wrote in his follow-up
> > messages.  I think DJGPP is doing the right thing using the SVR4
> > scheme for DWARF2 while staying backwards compatible for stabs.  I'd
> > advise him to do the same for cygwin.
>
> Ok, do I need approval to revert my own patch ;-) ?
>
> 2004-04-19  Brian Ford  <ford@vss.fsi.com>
>
> 	Revert 2004-04-16 change.
> 	* i386-tdep.c (i386_gdbarch_init): Fix comment typos.
> 	(i386_coff_init_abi): Remove.
> 	* i386-tdep.h (i386_coff_init_abi): Remove.
> 	* i386-cygwin-tdep.c (i386_cygwin_init_abi): Remove call to above.
>
> > If i386_coff_init_abi will be gone, the comments aren't contradictiory
> > anymore.
>
> Not exactly, as Eli pointed out before, both of the following will be
> false for DJGPP and Cygwin/Mingw:
>
>      Currently, each GCC i386 target always uses the same register
>      numbering scheme across all its supported debugging formats
>      i.e. SDB (COFF), stabs and DWARF 2.  This is because
>      gcc/sdbout.c, gcc/dbxout.c and gcc/dwarf2out.c all use the
>      DBX_REGISTER_NUMBER macro which is defined by each target's
>      respective config header in a manner independent of the requested
>      output debugging format.
>
> > On Mon, 19 Apr 2004 at 08:50:59 +0200, Eli Zaretskii wrote:
> >
> >> On Sun, 18 Apr 2004 20:38:38 +0200 (CEST), Mark Kettenis wrote:
> >>
> >>>+     floating-point registers, and are implemented by the attays
> >> 							        ^^^^^^
> >> A typo.
> >
> > I though I'd fixed that one :-(.
>
> and another:
>
>      implemented in dbx64_register_map, and us used for AMD64; see
>                                             ^^
> both of which are fixed in the attached patch.  Ok to apply?

-- 
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: 3503 bytes --]

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.187
diff -u -p -r1.187 i386-tdep.c
--- i386-tdep.c	18 Apr 2004 18:38:04 -0000	1.187
+++ i386-tdep.c	20 Apr 2004 16:18:37 -0000
@@ -1782,16 +1782,6 @@ i386_svr4_sigcontext_addr (struct frame_
 }
 \f
 
-/* Generic COFF.  */
-
-void
-i386_coff_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
-{
-  /* We typically use DWARF-in-COFF with the dbx 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
@@ -1995,12 +1985,12 @@ i386_gdbarch_init (struct gdbarch_info i
   /* NOTE: kettenis/20040418: 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, and are implemented by the attays
+     floating-point registers, and are implemented by the arrays
      dbx_register_map[] and svr4_dbx_register_map in
      gcc/config/i386.c.  GCC also defines a third numbering scheme in
      gcc/config/i386.c, which it designates as the "default" register
      map used in 64bit mode.  This last register numbering scheme is
-     implemented in dbx64_register_map, and us used for AMD64; see
+     implemented in dbx64_register_map, and is used for AMD64; see
      amd64-tdep.c.
 
      Currently, each GCC i386 target always uses the same register
@@ -2019,8 +2009,8 @@ i386_gdbarch_init (struct gdbarch_info i
      native compiler (FreeBSD, NetBSD, OpenBSD, GNU/Linux) or for
      targets where the native toolchain uses a different numbering
      scheme for a particular debug format (stabs-in-ELF on Solaris)
-     the defaults below will have to be overridden, like the functions
-     i386_coff_init_abi() and i386_elf_init_abi() do.  */
+     the defaults below will have to be overridden, like
+     i386_elf_init_abi() does.  */
 
   /* Use the dbx register numbering scheme for stabs and COFF.  */
   set_gdbarch_stab_reg_to_regnum (gdbarch, i386_dbx_reg_to_regnum);
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.39
diff -u -p -r1.39 i386-tdep.h
--- i386-tdep.h	16 Apr 2004 16:49:55 -0000	1.39
+++ i386-tdep.h	20 Apr 2004 16:18:37 -0000
@@ -210,9 +210,6 @@ 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.4
diff -u -p -r1.4 i386-cygwin-tdep.c
--- i386-cygwin-tdep.c	16 Apr 2004 16:49:55 -0000	1.4
+++ i386-cygwin-tdep.c	20 Apr 2004 16:18:37 -0000
@@ -31,8 +31,6 @@ 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;
 }
 

[Patch ping] Re: COFF & mixed debug formats

[Brian Ford]

Well, it's been another week.  Anybody want to step in here?

It's a pretty simple patch; just a cut and paste from elfread.c.

On Fri, 16 Apr 2004, Brian Ford wrote:

> On Fri, 16 Apr 2004, Christopher Faylor wrote:
>> Who can approve the COFF stuff?
>>
>> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
>>> 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.
>
> At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
> give him a week or so to respond.

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

Re: [PATCH] Proper _to_regnum for DWARF on Cygwin

[Mark Kettenis]

   Date: Tue, 20 Apr 2004 11:30:22 -0500
   From: Brian Ford <ford@vss.fsi.com>

   Oops, missed the comment refering to the removed function.  Updated patch
   attached.  ChangeLog unchanged from below.  Ok to apply?

Yes, please add yourself to the MAINTERS file under "Write After
Approval".  After you've done so, please check in the patch
seperately.

Cheers,

Mark

   On Mon, 19 Apr 2004, Brian Ford wrote:

   > On Mon, 19 Apr 2004, Mark Kettenis wrote:
   >
   > > Hmm.  I very much agree with what Brian wrote in his follow-up
   > > messages.  I think DJGPP is doing the right thing using the SVR4
   > > scheme for DWARF2 while staying backwards compatible for stabs.  I'd
   > > advise him to do the same for cygwin.
   >
   > Ok, do I need approval to revert my own patch ;-) ?
   >
   > 2004-04-19  Brian Ford  <ford@vss.fsi.com>
   >
   > 	Revert 2004-04-16 change.
   > 	* i386-tdep.c (i386_gdbarch_init): Fix comment typos.
   > 	(i386_coff_init_abi): Remove.
   > 	* i386-tdep.h (i386_coff_init_abi): Remove.
   > 	* i386-cygwin-tdep.c (i386_cygwin_init_abi): Remove call to above.
   >
   > > If i386_coff_init_abi will be gone, the comments aren't contradictiory
   > > anymore.

Re: [Patch ping] Re: COFF & mixed debug formats

[Brian Ford]

If I'm being too persistent, just tell me to go sit quietly on my hands
for a while ;-).  This patch is almost a month old now, though.

http://sources.redhat.com/ml/gdb-patches/2004-03/msg00548.html

Thanks.

On Wed, 21 Apr 2004, Brian Ford wrote:

> Well, it's been another week.  Anybody want to step in here?
>
> It's a pretty simple patch; just a cut and paste from elfread.c.
>
> On Fri, 16 Apr 2004, Brian Ford wrote:
>
> > On Fri, 16 Apr 2004, Christopher Faylor wrote:
> >> Who can approve the COFF stuff?
> >>
> >> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
> >>> 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.
> >
> > At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
> > give him a week or so to respond.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

Re: [Patch ping] Re: COFF & mixed debug formats

[Brian Ford]

Ping.

On Fri, 30 Apr 2004, Brian Ford wrote:

> If I'm being too persistent, just tell me to go sit quietly on my hands
> for a while ;-).  This patch is almost a month old now, though.
>
> http://sources.redhat.com/ml/gdb-patches/2004-03/msg00548.html
>
> Thanks.
>
> On Wed, 21 Apr 2004, Brian Ford wrote:
>
> > Well, it's been another week.  Anybody want to step in here?
> >
> > It's a pretty simple patch; just a cut and paste from elfread.c.
> >
> > On Fri, 16 Apr 2004, Brian Ford wrote:
> >
> > > On Fri, 16 Apr 2004, Christopher Faylor wrote:
> > >> Who can approve the COFF stuff?
> > >>
> > >> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
> > >>> 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.
> > >
> > > At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
> > > give him a week or so to respond.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

Re: [Patch ping] Re: COFF & mixed debug formats

[Brian Ford]

Ping.

On Mon, 17 May 2004, Brian Ford wrote:

> Ping.
>
> On Fri, 30 Apr 2004, Brian Ford wrote:
>
> > If I'm being too persistent, just tell me to go sit quietly on my hands
> > for a while ;-).  This patch is almost a month old now, though.
> >
> > http://sources.redhat.com/ml/gdb-patches/2004-03/msg00548.html
> >
> > Thanks.
> >
> > On Wed, 21 Apr 2004, Brian Ford wrote:
> >
> > > Well, it's been another week.  Anybody want to step in here?
> > >
> > > It's a pretty simple patch; just a cut and paste from elfread.c.
> > >
> > > On Fri, 16 Apr 2004, Brian Ford wrote:
> > >
> > > > On Fri, 16 Apr 2004, Christopher Faylor wrote:
> > > >> Who can approve the COFF stuff?
> > > >>
> > > >> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
> > > >>> 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.
> > > >
> > > > At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
> > > > give him a week or so to respond.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...

Re: [Patch ping] Re: COFF & mixed debug formats

[Daniel Jacobowitz]

At this point it seems apparent that Philippe De Muyter is not going to
respond.  By analogy with the other symbol readers I believe this patch
is obviously correct and can be committed; does anyone disagree?

On Wed, Jun 09, 2004 at 10:18:11AM -0500, Brian Ford wrote:
> Ping.
> 
> On Mon, 17 May 2004, Brian Ford wrote:
> 
> > Ping.
> >
> > On Fri, 30 Apr 2004, Brian Ford wrote:
> >
> > > If I'm being too persistent, just tell me to go sit quietly on my hands
> > > for a while ;-).  This patch is almost a month old now, though.
> > >
> > > http://sources.redhat.com/ml/gdb-patches/2004-03/msg00548.html
> > >
> > > Thanks.
> > >
> > > On Wed, 21 Apr 2004, Brian Ford wrote:
> > >
> > > > Well, it's been another week.  Anybody want to step in here?
> > > >
> > > > It's a pretty simple patch; just a cut and paste from elfread.c.
> > > >
> > > > On Fri, 16 Apr 2004, Brian Ford wrote:
> > > >
> > > > > On Fri, 16 Apr 2004, Christopher Faylor wrote:
> > > > >> Who can approve the COFF stuff?
> > > > >>
> > > > >> On Tue, Apr 13, 2004 at 03:12:42PM -0500, Brian Ford wrote:
> > > > >>> 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.
> > > > >
> > > > > At Jim Blandy's suggestion, I pinged him personally on Wednesday.  Let's
> > > > > give him a week or so to respond.
> 
> -- 
> Brian Ford
> Senior Realtime Software Engineer
> VITAL - Visual Simulation Systems
> FlightSafety International
> the best safety device in any aircraft is a well-trained pilot...
> 

-- 
Daniel Jacobowitz

Re: [Patch ping] Re: COFF & mixed debug formats

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> At this point it seems apparent that Philippe De Muyter is not going to
> respond.  By analogy with the other symbol readers I believe this patch
> is obviously correct and can be committed; does anyone disagree?

Nope.  I've said I thought it looked good a long while ago.

Re: [Patch ping] Re: COFF & mixed debug formats

[Christopher Faylor]

On Wed, Jun 09, 2004 at 04:23:33PM -0500, Jim Blandy wrote:
>Daniel Jacobowitz <drow@false.org> writes:
>> At this point it seems apparent that Philippe De Muyter is not going to
>> respond.  By analogy with the other symbol readers I believe this patch
>> is obviously correct and can be committed; does anyone disagree?
>
>Nope.  I've said I thought it looked good a long while ago.

So, go for it Brian!

cgf

Re: [Patch ping] Re: COFF & mixed debug formats

[Brian Ford]

On Wed, 9 Jun 2004, Christopher Faylor wrote:

> On Wed, Jun 09, 2004 at 04:23:33PM -0500, Jim Blandy wrote:
> >Daniel Jacobowitz writes:
> >> At this point it seems apparent that Philippe De Muyter is not going to
> >> respond.  By analogy with the other symbol readers I believe this patch
> >> is obviously correct and can be committed; does anyone disagree?
> >
> >Nope.  I've said I thought it looked good a long while ago.
>
> So, go for it Brian!

Thanks, applied.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...