[PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

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

I noticed this while tracking down another problem with adding DWARF2
support to Cygwin.  (Jim Blandy knows which one.  Thanks again Jim :^),
and this is not necessarily related to that.)

In gcc/config/i386/i386.c, we have:

/* The "default" register map used in 32bit mode.  */

int const dbx_register_map[FIRST_PSEUDO_REGISTER] =
{
  0, 2, 1, 3, 6, 7, 4, 5,               /* general regs */
  12, 13, 14, 15, 16, 17, 18, 19,       /* fp regs */
  -1, -1, -1, -1, -1,                   /* arg, flags, fpsr, dir, frame */
  21, 22, 23, 24, 25, 26, 27, 28,       /* SSE */
  29, 30, 31, 32, 33, 34, 35, 36,       /* MMX */
  -1, -1, -1, -1, -1, -1, -1, -1,       /* extended integer registers */
  -1, -1, -1, -1, -1, -1, -1, -1,       /* extended SSE registers */
};

and:

/* Define the register numbers to be used in Dwarf debugging information. */

int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =
{
  0, 2, 1, 3, 6, 7, 5, 4,               /* general regs */
  11, 12, 13, 14, 15, 16, 17, 18,       /* fp regs */
  -1, 9, -1, -1, -1,                    /* arg, flags, fpsr, dir, frame */
  21, 22, 23, 24, 25, 26, 27, 28,       /* SSE registers */
  29, 30, 31, 32, 33, 34, 35, 36,       /* MMX registers */
  -1, -1, -1, -1, -1, -1, -1, -1,       /* extended integer registers */
  -1, -1, -1, -1, -1, -1, -1, -1,       /* extended SSE registers */
};

Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5
respectively in the "default" (aka dbx, stabs, sdb) table.  But, in
the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and
4 respectively.

I'm not sure if/how this should affect i386_register_names.  I also hope
that targets have not already coded around this bug so that fixing it will
break something else :-).  Please do have a look at these issues before
applying the patch.  I'm afraid they are over my head right now.

Thanks.

2004-03-31  Brian Ford  <ford@vss.fsi.com>

	* i386-tdep.c (i386_stab_reg_to_regnum): Reverse 4 and 5
	(ebp and esp respectively) to match the gdb/DWARF regnums.

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

Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.181
diff -u -p -r1.181 i386-tdep.c
--- i386-tdep.c	23 Mar 2004 14:47:56 -0000	1.181
+++ i386-tdep.c	31 Mar 2004 23:25:52 -0000
@@ -175,8 +175,10 @@ i386_stab_reg_to_regnum (int reg)
   /* This implements what GCC calls the "default" register map.  */
   if (reg >= 0 && reg <= 7)
     {
-      /* General-purpose registers.  */
-      return reg;
+      /* General-purpose registers.
+	 ebp and esp (4, 5) are reversed with respect to gdb and DWARF. */
+
+      return (reg & 6) == 4 ? reg ^ 1 : reg;
     }
   else if (reg >= 12 && reg <= 19)
     {

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5
> respectively in the "default" (aka dbx, stabs, sdb) table.  But, in
> the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and
> 4 respectively.
> 
> I'm not sure if/how this should affect i386_register_names.  I also hope
> that targets have not already coded around this bug so that fixing it will
> break something else :-).  Please do have a look at these issues before
> applying the patch.  I'm afraid they are over my head right now.

Yeah, wow.  So, one thing that surprised me is that, for any given
platform, GCC always uses the same register numbering in STABS and
Dwarf 2 --- gcc/dwarf2out.c and gcc/dbxout.c both use
DBX_REGISTER_NUMBER.  But if that's so, why does gdb/i386-tdep.c have
two separate (and different!) STABS and Dwarf register number
functions?

The points where they differ are in the numbering of the
floating-point registers, and in numbering %eip and %eflags.  But it
doesn't look to me as if Dwarf and STABS actually do differ in the
numbering of floating-point registers:

$ cat fpregs.c
#include <stdio.h>
#include <stdlib.h>

double
foo (register int n)
{
  register int i;
  register double a = n * 1.5;
  register double b = n * 2.25;
  register double c = n * 3.125;
  register double d = n * 4.0625;
  register double e = n * 5.03125;

  for (i = 0; i < n; i++)
    {
      if (i & 1)  a = b + c; else a = c + e;
      if (i & 2)  b = c + d; else b = d + a;
      if (i & 4)  c = d + e; else c = e + b;
      if (i & 8)  d = e + a; else d = a + c;
      if (i & 16) e = a + b; else e = b + d;
    }

  return a + b + c + d + e;
}


int
main (int argc, char **argv)
{
  if (argc == 2)
    printf ("%lf\n", foo (atoi (argv[1])));
}
$ gcc33 gcc -g -O fpregs.c -o fpregs
$ readelf -wi fpregs > fpregs.wi~
$ gcc33 gcc -gstabs+ -O fpregs.c -o fpregs
$ objdump --stabs fpregs > fpregs.stabs~
$

If I look at what fpregs.stabs~ says about foo's local variables, I
see:

268    RSYM   0      5      00000002 9327   n:r(0,1)
269    RSYM   0      7      00000000 9336   i:r(0,1)
270    RSYM   0      8      0000000f 9345   a:r(0,13)
271    RSYM   0      9      0000000b 9355   b:r(0,13)
272    RSYM   0      10     0000000e 9365   c:r(0,13)
273    RSYM   0      11     0000000d 9375   d:r(0,13)
274    RSYM   0      12     0000000c 9385   e:r(0,13)

The fifth column is the stab's value, which is the register number.  'a'
is assigned to register 15, 'b' is assigned register 11, and so on.

In fpregs.wi~, I see:

 <2><1da2>: Abbrev Number: 31 (DW_TAG_formal_parameter)
     DW_AT_name        : n	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 5	
     DW_AT_type        : <d0f>	
     DW_AT_location    : 1 byte block: 52 	(DW_OP_reg2; )
 <2><1dad>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : i	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 7	
     DW_AT_type        : <d0f>	
     DW_AT_location    : 1 byte block: 50 	(DW_OP_reg0; )
 <2><1db8>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : a	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 8	
     DW_AT_type        : <1df0>	
     DW_AT_location    : 1 byte block: 5f 	(DW_OP_reg15; )
 <2><1dc3>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : b	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 9	
     DW_AT_type        : <1df0>	
     DW_AT_location    : 1 byte block: 5b 	(DW_OP_reg11; )
 <2><1dce>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : c	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 10	
     DW_AT_type        : <1df0>	
     DW_AT_location    : 1 byte block: 5e 	(DW_OP_reg14; )
 <2><1dd9>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : d	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 11	
     DW_AT_type        : <1df0>	
     DW_AT_location    : 1 byte block: 5d 	(DW_OP_reg13; )
 <2><1de4>: Abbrev Number: 32 (DW_TAG_variable)
     DW_AT_name        : e	
     DW_AT_decl_file   : 1	
     DW_AT_decl_line   : 12	
     DW_AT_type        : <1df0>	
     DW_AT_location    : 1 byte block: 5c 	(DW_OP_reg12; )

In other words, GCC is using the same numbering for floating-point
registers in both formats --- which verifies what we expected from
looking at the code anyway.  So we're not crazy.

So I think the best fix is to have i386-tdep.c use two register number
translation functions that correspond to gcc/config/i386/i386.c's
dbx_register_map and svr4_dbx_register_map, and then register one
function or the other as both the stabs and dwarf 2 translation
functions, as appropriate for a given platform.

The problem is that this affects lots of other targets, which we can't
test.  And it assumes that GCC has its register numberings right on
all those targets.  I have no idea whether it does.

Having said all that, I'd guess the right immediate fix is to register
an osabi handler for GDB_OSABI_CYGWIN, down at the bottom of
gdb/i386-tdep.c:_initialize_i386_tdep, that plugs in the right
gdbarch_dwarf2_reg_to_regnum function for Cygwin.  And leave the
existing _to_regnum functions unchanged.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Thu, 1 Apr 2004, Jim Blandy wrote:

> Brian Ford <ford@vss.fsi.com> writes:
> > Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5
> > respectively in the "default" (aka dbx, stabs, sdb) table.  But, in
> > the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and
> > 4 respectively.
> >
> > I'm not sure if/how this should affect i386_register_names.  I also hope
> > that targets have not already coded around this bug so that fixing it will
> > break something else :-).  Please do have a look at these issues before
> > applying the patch.  I'm afraid they are over my head right now.
>
> Yeah, wow.  So, one thing that surprised me is that, for any given
> platform, GCC always uses the same register numbering in STABS and
> Dwarf 2 --- gcc/dwarf2out.c and gcc/dbxout.c both use
> DBX_REGISTER_NUMBER.  But if that's so, why does gdb/i386-tdep.c have
> two separate (and different!) STABS and Dwarf register number
> functions?

Actually, that's not true.  In fact, that is how I'm planning on fixing
my/our original problem :^).  In gcc/config/i386/cygming.h:

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

> The points where they differ are in the numbering of the
> floating-point registers, and in numbering %eip and %eflags.

And, of course, ebp and esp :).

> But it doesn't look to me as if Dwarf and STABS actually do differ in
> the numbering of floating-point registers:

That depends on the target ;-).  And, it is the reason why gdb/i386-tdep.c
(i386_elf_init_abi) exists.

I chose the fix above to preserve forward and backward compatibility.

> $ cat fpregs.c
[snip]
> In other words, GCC is using the same numbering for floating-point
> registers in both formats --- which verifies what we expected from
> looking at the code anyway.  So we're not crazy.

I assume this was all on i?86 Linux?  It doesn't use a different
numbering scheme.  See the previous comment.

> So I think the best fix is to have i386-tdep.c use two register number
> translation functions that correspond to gcc/config/i386/i386.c's
> dbx_register_map and svr4_dbx_register_map, and then register one
> function or the other as both the stabs and dwarf 2 translation
> functions, as appropriate for a given platform.
>
No, nothing is broken/wrong other than what I pointed out.  You just
didn't "get" all the details yet.

BTW, I didn't mention it to avoid confusion, but there is also a
dbx64_register_map.  It is unconditionally used in 64 bit mode by
all targets that support it for all debug formats. I don't see how
gdb handles that at all, but I didn't care that much since Cygwin
doesn't currently support 64 bit mode :-).

> The problem is that this affects lots of other targets, which we can't
> test.  And it assumes that GCC has its register numberings right on
> all those targets.  I have no idea whether it does.
>
I've looked at most of them in detail trying to compare differences if it
matters.

> Having said all that, I'd guess the right immediate fix is to register
> an osabi handler for GDB_OSABI_CYGWIN, down at the bottom of
> gdb/i386-tdep.c:_initialize_i386_tdep, that plugs in the right
> gdbarch_dwarf2_reg_to_regnum function for Cygwin.  And leave the
> existing _to_regnum functions unchanged.
>
I disagree.  Has your opinion changed now?

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> On Thu, 1 Apr 2004, Jim Blandy wrote:
> 
> > Brian Ford <ford@vss.fsi.com> writes:
> > > Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5
> > > respectively in the "default" (aka dbx, stabs, sdb) table.  But, in
> > > the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and
> > > 4 respectively.
> > >
> > > I'm not sure if/how this should affect i386_register_names.  I also hope
> > > that targets have not already coded around this bug so that fixing it will
> > > break something else :-).  Please do have a look at these issues before
> > > applying the patch.  I'm afraid they are over my head right now.
> >
> > Yeah, wow.  So, one thing that surprised me is that, for any given
> > platform, GCC always uses the same register numbering in STABS and
> > Dwarf 2 --- gcc/dwarf2out.c and gcc/dbxout.c both use
> > DBX_REGISTER_NUMBER.  But if that's so, why does gdb/i386-tdep.c have
> > two separate (and different!) STABS and Dwarf register number
> > functions?
> 
> Actually, that's not true.  In fact, that is how I'm planning on fixing
> my/our original problem :^).  In gcc/config/i386/cygming.h:
> 
> #undef DBX_REGISTER_NUMBER
> #define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG   \
>                                 ? svr4_dbx_register_map[n]      \
>                                 : dbx_register_map[n])

Aside from the one you're introducing here, the only other
target/platform where Dwarf and STABS have different register
numberings is the rs6000.  Of the 33 other #definitions of
DBX_REGISTER_NUMBER in the tree, none of them make this distinction.

On all i386-based platforms, the numbering is the same, as far as I
can see from the GCC sources.

> > But it doesn't look to me as if Dwarf and STABS actually do differ in
> > the numbering of floating-point registers:
> 
> That depends on the target ;-).  And, it is the reason why gdb/i386-tdep.c
> (i386_elf_init_abi) exists.
>
> I chose the fix above to preserve forward and backward
> compatibility.

Sorry --- is there an existing toolchain using Dwarf 2 on Windows?  If
not, then what existing tools, already in use by others, are you being
forward and backward compatible with?

I thought we were the first people to put Dwarf 2 in COFF at all.  If
that's the case, we get to choose the numbering as best makes sense.
And it seems to me there's pretty clear precedent for using the same
numbering in both STABS and Dwarf.

> BTW, I didn't mention it to avoid confusion, but there is also a
> dbx64_register_map.  It is unconditionally used in 64 bit mode by
> all targets that support it for all debug formats. I don't see how
> gdb handles that at all, but I didn't care that much since Cygwin
> doesn't currently support 64 bit mode :-).

It's the AMD x86_64 stuff.  Yes, it's not relevant to us here.

> > Having said all that, I'd guess the right immediate fix is to register
> > an osabi handler for GDB_OSABI_CYGWIN, down at the bottom of
> > gdb/i386-tdep.c:_initialize_i386_tdep, that plugs in the right
> > gdbarch_dwarf2_reg_to_regnum function for Cygwin.  And leave the
> > existing _to_regnum functions unchanged.
> >
> I disagree.  Has your opinion changed now?

I don't yet understand what you're preserving compatibility with.  If
there are extant toolchains we need to match, then that's definitely
important.  But it's my understanding that we're breaking new ground
here; if that's so, we should break that ground consistently with
existing GNU toolchain targets.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Thu, 1 Apr 2004, Jim Blandy wrote:

> Brian Ford <ford@vss.fsi.com> writes:
> > On Thu, 1 Apr 2004, Jim Blandy wrote:
> > > Brian Ford <ford@vss.fsi.com> writes:
> > > > Notice that gcc regno 6 (ebp) and 7 (esp) map to regno 4 and 5
> > > > respectively in the "default" (aka dbx, stabs, sdb) table.  But, in
> > > > the svr4 (aka dwarf, dwarf2, stabs-in-elf) table, they map to regno 5 and
> > > > 4 respectively.
> > > >
> > > > I'm not sure if/how this should affect i386_register_names.  I also hope
> > > > that targets have not already coded around this bug so that fixing it will
> > > > break something else :-).  Please do have a look at these issues before
> > > > applying the patch.  I'm afraid they are over my head right now.
> > >
> > > Yeah, wow.  So, one thing that surprised me is that, for any given
> > > platform, GCC always uses the same register numbering in STABS and
> > > Dwarf 2 --- gcc/dwarf2out.c and gcc/dbxout.c both use
> > > DBX_REGISTER_NUMBER.  But if that's so, why does gdb/i386-tdep.c have
> > > two separate (and different!) STABS and Dwarf register number
> > > functions?
> > >
I'm not clear on how you are defining platform here.  i386-tdep.c is used
by multiple i386 ABIs.  Those ABIs do differ in their register numbering.
Maybe none currently do within themselves between DWARF and STABS, but
they definately do between ABI's.  Maybe the register numbering
functions should be called dbx and svr4, like in gcc, instead of dwarf and
stabs.

> > Actually, that's not true.  In fact, that is how I'm planning on fixing
> > my/our original problem :^).  In gcc/config/i386/cygming.h:
> >
> > #undef DBX_REGISTER_NUMBER
> > #define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG   \
> >                                 ? svr4_dbx_register_map[n]      \
> >                                 : dbx_register_map[n])
>
> Aside from the one you're introducing here, the only other
> target/platform where Dwarf and STABS have different register
> numberings is the rs6000.  Of the 33 other #definitions of
> DBX_REGISTER_NUMBER in the tree, none of them make this distinction.
>
Ok, I just re-did a simple grep, and that even missed the rs6000 case
because it uses a function for the definition.  I'll take your word for
it, though.

There used to be many more, but they've either been changed or
depricated.  I used a bit of ChangeLog digging and cvs history diving to
come up with this fix in the first place.  When dbx_register_map and
svr4_register_map were first introduced, this was not uncommon (osfrose
was where I first found it).

> On all i386-based platforms, the numbering is the same, as far as I
> can see from the GCC sources.
>
Once again, between DWARF and STABS within an ABI, maybe.  Between ABIs,
definately not.

> > > But it doesn't look to me as if Dwarf and STABS actually do differ in
> > > the numbering of floating-point registers:
> >
> > That depends on the target ;-).  And, it is the reason why gdb/i386-tdep.c
> > (i386_elf_init_abi) exists.
> >
> > I chose the fix above to preserve forward and backward
> > compatibility.
>
> Sorry --- is there an existing toolchain using Dwarf 2 on Windows?  If
> not, then what existing tools, already in use by others, are you being
> forward and backward compatible with?
>
This isn't really relevant, but DJGPP does.  It appears to me that they
use the dbx_register_map for DWARF2.  So, I don't understand why they
don't have the problem my patch was trying to address.

My compatability concern was backward with STABS, ie. I don't want to
change the register numbering scheme for it that already exists.

> I thought we were the first people to put Dwarf 2 in COFF at all.
> If that's the case, we get to choose the numbering as best makes sense.
> And it seems to me there's pretty clear precedent for using the same
> numbering in both STABS and Dwarf.
>
Given the DJGPP caveat, yes, and agreed to some extent.

The forward part of my compatability argument is that all known working
(I still don't understand how DJGPP is working without my patch) i386 targets
with DWARF2 support use the svr4_register_numbering scheme.  So, I was
trying to go with that precident instead of the one you observed.

> > > Having said all that, I'd guess the right immediate fix is to register
> > > an osabi handler for GDB_OSABI_CYGWIN, down at the bottom of
> > > gdb/i386-tdep.c:_initialize_i386_tdep, that plugs in the right
> > > gdbarch_dwarf2_reg_to_regnum function for Cygwin.  And leave the
> > > existing _to_regnum functions unchanged.
> > >
The handler is already registed in i386-cygwin-tdep.c
(_initialize_i386_cygwin_tdep).  Since those functions are in a cygwin
specific file, and since the _to_regnum functions are static, something
would have to change ;-).

But, leaving the existing _to_regnum functions unchanged won't work for
your option.  That is what lead me to, and why I posted the patch in the
first place.  For my option, the bug that the patch addresses doesn't
seem to bit me/us.  I just thought I'd correct it since I found it.
Either way, I'm happy.

> I don't yet understand what you're preserving compatibility with.  If
> there are extant toolchains we need to match, then that's definitely
> important.  But it's my understanding that we're breaking new ground
> here; if that's so, we should break that ground consistently with
> existing GNU toolchain targets.
>
I all depends on your definition of consistency, and how much you're
willing break in getting there.

Please let me know what you think is best.  Thanks for your volunteer
time, too.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Thu, 1 Apr 2004 16:54:46 -0600 (CST)
> From: Brian Ford <ford@vss.fsi.com>
> >
> > Sorry --- is there an existing toolchain using Dwarf 2 on Windows?  If
> > not, then what existing tools, already in use by others, are you being
> > forward and backward compatible with?
> >
> This isn't really relevant

Why not?

> but DJGPP does.

That's true: DJGPP does support DWARF2 debug info in COFF object file
format.

> It appears to me that they use the dbx_register_map for DWARF2.  So,
> I don't understand why they don't have the problem my patch was
> trying to address.

I marked this thread for checking, but never had time to do it.  If
you can send me a sample program and a description of what I should do
to see whether DJGPP has the same problem, I will gladly try that and
report the results.  Please also tell what versions of GCC and GDB
should I try.

> The forward part of my compatability argument is that all known working
> (I still don't understand how DJGPP is working without my patch) i386 targets
> with DWARF2 support use the svr4_register_numbering scheme.  So, I was
> trying to go with that precident instead of the one you observed.

Some time ago I did find a problem in register numbering, and IIRC it
was fixed, although I don't recall the details and don't see anything
in the logs.  Perhaps the fix was in GCC rather than GDB.  And I don't
remember whether I looked at EBP and ESP back then.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Fri, 2 Apr 2004, Eli Zaretskii wrote:

> On Thu, 1 Apr 2004, Brian Ford wrote:
> > On Thu, 1 Apr 2004, Jim Blandy wrote:
> > > Sorry --- is there an existing toolchain using Dwarf 2 on Windows?  If
> > > not, then what existing tools, already in use by others, are you being
> > > forward and backward compatible with?
> >
> > This isn't really relevant
>
> Why not?

Well first, it's not really Windows, it's DOS.  Secondly, it's pure
COFF with a custom loader, as I understand, not PE/COFF.

I just don't see any reason to try and be "compatible" with it.  I'm not
even sure what that means?  I certainly don't want to break it,
though.

> > but DJGPP does.
>
> That's true: DJGPP does support DWARF2 debug info in COFF object file
> format.
>
> > It appears to me that they use the dbx_register_map for DWARF2.  So,
> > I don't understand why they don't have the problem my patch was
> > trying to address.

Actually, I understand why my patch would not even affect them.  But,
that's a bug, not a feature :-).  I don't understand why they don't have
even *bigger* problems, though.  See the explanation below.

> I marked this thread for checking, but never had time to do it.  If
> you can send me a sample program and a description of what I should do
> to see whether DJGPP has the same problem, I will gladly try that and
> report the results.  Please also tell what versions of GCC and GDB
> should I try.
>
You mean source code, right?  You would obviously need a DJGPP toolchain
for testing.  I don't have one right now.

A sample program would be trivial, so you might as well make one yourself.
Just throw in some stack variables, preferably some in main, and some in
a function called from main.  Oh, and make a few of them floating point
so you can test that too.

As for the gcc/gdb versions, I don't really think it matters much.  The
only ones I have looked at in detail and expect to contain the bug are
gcc 3.4+ and cvs HEAD gdb.  Don't let these version numbers get in the way
of your test, though.  Try whatever you have laying around (if you do have
something laying around).

Let me try to explain what I think you will find.  As I said before, it
appears that DJGPP uses the dbx_register_map for DWARF 2 in gcc.
Currently, all targets using i386-tdep.c in gdb use the
i386_dwarf_reg_to_regnum translation function for DWARF 2.  That function
corresponds to the svr4_register_map in gcc.  i386_stabs_reg_to_regnum is
supposed to correspond to the dbx_register_map, but it only does so after
my patch.  Here are the differences in the two maps:

register #'s	dbx				svr4
esp		5				4
ebp		4				5
fp regs		12-19				11-18
flags		-1				9

If gdb can properly find and print the values for variables on the stack
and in floating point registers, then DJGPP must have coded around the
differences.  ie. It must not use the gdb standard numbering scheme
like other targets.

Also, if you can dump the DWARF 2 information, look for the
DW_AT_frame_base attribute.  See if that is set to DW_op_reg4, or
DW_op_reg5.  That should tell you which register number is being used for
ebp, and thus which register map was used in gcc.

I contend that to use the standard gdb regnums, DJGPP should be using the
i386_stabs_reg_to_regnum function (with my patch) for DWARF 2
translations.  (I still think those functions should be renamed to dbx
and svr4 instead of stabs and dwarf).  If DJGPP currently works, then the
go32 backend needs to be adjusted as well so it conforms to the gdb standard
regnums.

There are just too many oportunities for translation here ;-).

> > The forward part of my compatability argument is that all known working
> > (I still don't understand how DJGPP is working without my patch) i386 targets
> > with DWARF2 support use the svr4_register_numbering scheme.  So, I was
> > trying to go with that precident instead of the one you observed.
>
> Some time ago I did find a problem in register numbering, and IIRC it
> was fixed, although I don't recall the details and don't see anything
> in the logs.  Perhaps the fix was in GCC rather than GDB.  And I don't
> remember whether I looked at EBP and ESP back then.
>
Well, I'd really like to stop talking about DJGPP and start fixing Cygwin
;-).  I'd also like to hear Jim's comments about my previous mail.

Thanks again.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Fri, 02 Apr 2004 09:41:23 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
> 
> Some time ago I did find a problem in register numbering, and IIRC it
> was fixed, although I don't recall the details and don't see anything
> in the logs.

Found it.  See the thread started by this message:

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Fri, 2 Apr 2004 11:31:33 -0600 (CST)
> From: Brian Ford <ford@vss.fsi.com>
> > >
> > > This isn't really relevant
> >
> > Why not?
> 
> Well first, it's not really Windows, it's DOS.  Secondly, it's pure
> COFF with a custom loader, as I understand, not PE/COFF.

Yes, true on both counts.  I guess I misunderstood the meaning of
``relevant'' in your original message.

> I just don't see any reason to try and be "compatible" with it.  I'm not
> even sure what that means?  I certainly don't want to break it,
> though.

Well, the only way to break DJGPP is if you modify code used by it as
well.  So any pieces of coffread.c or dwarf2read.c, or anything in
i386-related files that is related to that, are possible areas of
interest.  If you only change Windows-specific files, you cannot
possibly break DJGPP (or any other non-Windows target).

However, what I'm really interested in is the possibility that a
similar problem exists in the DJGPP port.

> > I marked this thread for checking, but never had time to do it.  If
> > you can send me a sample program and a description of what I should do
> > to see whether DJGPP has the same problem, I will gladly try that and
> > report the results.  Please also tell what versions of GCC and GDB
> > should I try.
> >
> You mean source code, right?  You would obviously need a DJGPP toolchain
> for testing.  I don't have one right now.

Well, I do have it, obviously: otherwise, how could I possibly be
maintaining the DJGPP port of GDB? ;-)

> A sample program would be trivial, so you might as well make one yourself.
> Just throw in some stack variables, preferably some in main, and some in
> a function called from main.  Oh, and make a few of them floating point
> so you can test that too.

I understand this, but given my total lack of free time, I'd
appreciate a specific worked-out example with commands you type and
what GDB prints in response.  I don't mean for you to install the
DJGPP development environment and try that, just do that with the
Windows tools where you encountered the problem.  All I want to see is
whether similar problems with EBP and ESP exist in the DJGPP port.

Of course, if you are not interested to see whether other i386 targets
have this problem, you are free to disregard my request.

Thanks in advance.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Fri, 2 Apr 2004, Eli Zaretskii wrote:

> > Some time ago I did find a problem in register numbering, and IIRC it
> > was fixed, although I don't recall the details and don't see anything
> > in the logs.
>
> Found it.  See the thread started by this message:
>
>   http://sources.redhat.com/ml/gdb/2001-07/msg00392.html
>
Thanks.  Things sure have changed since then, haven't they ;-).

Some comments:

> (Btw, I don't see any COFF_REG_TO_REGNUM.)
>
Now that is set_gdbarch_sdb_reg_to_regnum, and it uses
i386_stab_reg_to_regnum.

Mark Kettenis wrote:

> With the patch that I just checked in, COFF and stabs should do the
> right thing for DJGPP.
>
Um..., except the ebp <-> esp thing.

> DWARF2 will probably still give you the wrong
> register.
>
Yup.  I don't see that you fixed that.

> You might want to consider changing GCC such that it uses
> the standard Dwarf renumbering for DWARF2.  I don't think it really
> matters since there aren't any native tools that you need to be
> compatible with.  On the other hand, using DWARF2 with a numbering
> scheme that nobody else uses, might trigger some bugs.
>
Precisely my reasoning (what do ya think, Jim?).

> If you don't change GCC you should probably override
> DWARF2_REG_TO_REGNO in config/i386/tm-go32.h.
>
You would now do that by calling set_gdbarch_dwarf2_reg_to_regnum in
i386_go32_init_abi with i386_stab_reg_to_regnum as the argument.

Andrew Cagney wrote:

> Yep.
>
> They map a stab/dwarf/... reg onto a cooked regnum (not to be confused
> with a raw reg found in the register cache).  Because the i386
> implements its registers using the old PSUEDO / CONVERT stuff, the
> importance of differentiating between the two may not be obvious.
>
Wish I knew how all this cooked regnum stuff worked.  That's why I can't
figure out a testcase for you.  If it's internally cooked wrong, but
straightened out by the back end, how do you tell?

> There is something here I don't get either.
>
> At present it is assumed that, for a given ISA/ABI, there is only one
> mapping from a DEBUG reg to a REGNUM.  I take it, Mark, that you're
> saying that in reality, the mapping depends on all of:
>
> (compiler, object format, debug format, ISA/ABI) (debug reg) -> REGNUM
>
> True? Ulgh!
>
True, and I think all the hooks are there to accomodate this.  They just
aren't all fully used/consistent yet.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Fri, 2 Apr 2004, Eli Zaretskii wrote:
> Brian Ford wrote talking about DJGPP:
> > I just don't see any reason to try and be "compatible" with it.  I'm not
> > even sure what that means?  I certainly don't want to break it,
> > though.
>
> Well, the only way to break DJGPP is if you modify code used by it as
> well.  So any pieces of coffread.c or dwarf2read.c, or anything in
> i386-related files that is related to that, are possible areas of
> interest.  If you only change Windows-specific files, you cannot
> possibly break DJGPP (or any other non-Windows target).
>
I understand that.

Getting back to the original subject, we're talking about fixing
i386_stab_reg_to_regnum.  That would affect DJGPP.  All indications are,
however, that the patch is correct.  If it breaks other targets, then
those other targets will need to be fixed again ;-).

> However, what I'm really interested in is the possibility that a
> similar problem exists in the DJGPP port.
>
It should, I just haven't figured out how to show you, especially if the
target backend has already "fixed" it.

> > Eli Zaretskii wrote:
> > > I marked this thread for checking, but never had time to do it.  If
> > > you can send me a sample program and a description of what I should do
> > > to see whether DJGPP has the same problem, I will gladly try that and
> > > report the results.  Please also tell what versions of GCC and GDB
> > > should I try.
> > >
> > You mean source code, right?  You would obviously need a DJGPP toolchain
> > for testing.  I don't have one right now.
>
> Well, I do have it, obviously: otherwise, how could I possibly be
> maintaining the DJGPP port of GDB? ;-)
>
Sorry, I wasn't looking carefully and didn't know (blush...).

> > A sample program would be trivial, so you might as well make one yourself.
> > Just throw in some stack variables, preferably some in main, and some in
> > a function called from main.  Oh, and make a few of them floating point
> > so you can test that too.
>
> I understand this, but given my total lack of free time, I'd
> appreciate a specific worked-out example with commands you type and
> what GDB prints in response.  I don't mean for you to install the
> DJGPP development environment and try that, just do that with the
> Windows tools where you encountered the problem.  All I want to see is
> whether similar problems with EBP and ESP exist in the DJGPP port.
>
Ok, I'm trying to find a simple step-by-step.

As a quick test, does a simple "bt" for a DWARF 2 compiled program stop at
main, or run off infinately?  What about for stabs?  That's one way to
tell about ebp <-> esp, maybe.

Can you try Jim's example program here compiled for DWARF 2?

http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html

Try an info address a in foo and see what you get.  That should confirm
Mark's suspicion about having the wrong register translation function for DWARF 2
on DJGPP.

Also, can you confirm the dumped DWARF info has a DW_AT_frame_base of
DW_OP_reg4, not 5?

How often does DJGPP use sdb, stabs, dwarf 2?  I just realized that DWARF
2 is not the default.

I've got to go out-of-town now for the weekend, but I'll work on an exact
step by step when I get back on Monday.

> Of course, if you are not interested to see whether other i386 targets
> have this problem, you are free to disregard my request.
>
I'm interested in fixing Cygwin.  I may need to change generic i386 code
to do that.  So, I guess I have to be interested ;-).

Thanks a lot for your help and comments.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Fri, 2 Apr 2004 17:15:51 -0600 (CST)
> From: Brian Ford <ford@vss.fsi.com>
> 
> Ok, I'm trying to find a simple step-by-step.

Thank you.

> As a quick test, does a simple "bt" for a DWARF 2 compiled program stop at
> main, or run off infinately?

It stops at main.  Here's a session transcript, using the test
program from the message you referred to:

> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html

and using a GDB snapshot from about a month ago:

D:\usr\djgpp\tmp>\gnu\gdb-0221\gdb\gdb ./fpregs
GNU gdb 20040221
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-pc-msdosdjgpp --target=djgpp"...
(gdb) b fpregs.c:14
Breakpoint 2 at 0x16f4: file fpregs.c, line 14.
(gdb) r 10

Starting program: d:/usr/djgpp/tmp/./fpregs 10

Breakpoint 2, foo (n=10) at fpregs.c:14
14        for (i = 0; i < n; i++)
(gdb) bt
#0  foo (n=10) at fpregs.c:14
#1  0x000017c5 in main (argc=2, argv=0xa) at fpregs.c:31
(gdb)

> What about for stabs?

In the same program compiled with -gstabs+, `bt' works correctly as
well:

D:\usr\djgpp\tmp>\gnu\gdb-0221\gdb\gdb ./fpregs_s
GNU gdb 20040221
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-pc-msdosdjgpp --target=djgpp"...
(gdb) b foo
Breakpoint 1 at 0x1616: file fpregs.c, line 8.
(gdb) r 10
Starting program: d:/usr/djgpp/tmp/./fpregs_s 10

Breakpoint 1, foo (n=10) at fpregs.c:8
8         register double a = n * 1.5;
(gdb) b 14
Breakpoint 2 at 0x1654: file fpregs.c, line 14.
(gdb) c
Continuing.

Breakpoint 2, foo (n=10) at fpregs.c:14
14        for (i = 0; i < n; i++)
(gdb) bt
#0  foo (n=10) at fpregs.c:14
#1  0x00001725 in main (argc=2, argv=0x20550) at fpregs.c:31
(gdb)

> Can you try Jim's example program here compiled for DWARF 2?
> 
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html
> 
> Try an info address a in foo and see what you get.

I get the following, no matter whether I compile with "-gstabs+" or
"-gdwarf-2":

(gdb) info address a
Symbol "a" is a variable in register st4.
(gdb) info address b
Symbol "b" is a variable in register st0.
(gdb) info address c
Symbol "c" is a variable in register st3.
(gdb) info address d
Symbol "d" is a variable in register st2.
(gdb) info address e
Symbol "e" is a variable in register st1.
(gdb)
(gdb) info address i
Symbol "i" is a variable in register eax.
(gdb) info address n
Symbol "n" is a variable in register edx.

> Also, can you confirm the dumped DWARF info has a DW_AT_frame_base of
> DW_OP_reg4, not 5?

I cannot use readelf here, since DJGPP binaries are COFF files, not
ELF files.  Is there a way to do this using objdump?

FWIW, in the program compiled with -gstabs+, the register allocation
I see is the same as Jim cited in his message:

63     RSYM   0      5      00000002 1564   n:r(0,1)
64     RSYM   0      7      00000000 1573   i:r(0,1)
65     RSYM   0      8      00000010 1582   a:r(0,13)
66     RSYM   0      9      0000000c 1592   b:r(0,13)
67     RSYM   0      10     0000000f 1602   c:r(0,13)
68     RSYM   0      11     0000000e 1612   d:r(0,13)
69     RSYM   0      12     0000000d 1622   e:r(0,13)

> How often does DJGPP use sdb, stabs, dwarf 2?

I don't have statistics (but see below).  I myself use all of them
roughly the same.

> I just realized that DWARF 2 is not the default.

Well, it is in DJGPP: GCC 3.2 and later use DWARF-2 by default.  So I
guess, for the random DJGPP user, DWARF-2 is much more frequent these
days that either -gstabs+ or -gcoff.

> I've got to go out-of-town now for the weekend, but I'll work on an exact
> step by step when I get back on Monday.

Thanks.

> I'm interested in fixing Cygwin.  I may need to change generic i386 code
> to do that.  So, I guess I have to be interested ;-).

I thought so, but given the fact that I wasn't following this thread
closely, I didn't want to make an impression that I'm tryion to twist
your hand to do something that is only tangentially related to your
patch.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]


Eli, here is a program you can use to see whether DJGPP's GCC and
the current GDB disagree on how to number %ebp and %esp.

One of the reasons people would tend not to notice if %ebp and %esp
are misnumbered in STABS is that they almost never occur.  Dwarf 2
emits explicit location expressions to specify the "frame base" for a
function; these expressions usually refer to %esp or %ebp.  In STABS,
however, stack-based variables are simply marked as "LSYMS" or
"PSYMS", whose locations are given as offsets relative to some
implicit base that the debugger just has to know.

So the only way to get those register numbers to appear at all is to
get a variable allocated to them.  You'll never get a variable
allocated to %esp.  And you'll never get a varable allocated to %ebp
unless you compile with -fomit-frame-pointer.  So, if I compile the
attached program with GCC 3.3 passing -O -fomit-frame-pointer, 'n'
gets allocated to %ebp.


[-- Attachment #2: test program to get a variable in %ebp --]
[-- Type: text/plain, Size: 609 bytes --]

#include <stdio.h>
#include <stdlib.h>

int
foo (register int n)
{
  register int i;
  register int a = n * 1;
  register int b = n * 2;
  register int c = n * 3;
  register int d = n * 4;
  register int e = n * 5;

  for (i = 0; i < n; i++)
    {
      if (i & 1)  a = b + c; else a = c + e;
      if (i & 2)  b = c + d; else b = d + a;
      if (i & 4)  c = d + e; else c = e + b;
      if (i & 8)  d = e + a; else d = a + c;
      if (i & 16) e = a + b; else e = b + d;
    }

  return a + b + c + d + e;
}


int
main (int argc, char **argv)
{
  if (argc == 2)
    printf ("%d\n", foo (atoi (argv[1])));
}

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

"Eli Zaretskii" <eliz@gnu.org> writes:
> I cannot use readelf here, since DJGPP binaries are COFF files, not
> ELF files.  Is there a way to do this using objdump?

No; objdump doesn't understand Dwarf 2.  What you can do is compile
with -gdwarf-2 -save-temps -dA, which will emit Dwarf 2, keep the
assembly file, and annotate the Dwarf 2 with human-readable comments.
For example:

	.uleb128 0x1f	# (DIE (0x1174) DW_TAG_formal_parameter)
	.ascii "n\0"	# DW_AT_name
	.byte	0x1	# DW_AT_decl_file
	.byte	0x5	# DW_AT_decl_line
	.long	0xe1	# DW_AT_type
	.byte	0x1	# DW_AT_location
	.byte	0x55	# DW_OP_reg5

(This die shows register 'n' being allocated to register 5.  Whatever
that is. :) )

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Mon, 5 Apr 2004, Jim Blandy wrote:

> Eli, here is a program you can use to see whether DJGPP's GCC and
> the current GDB disagree on how to number %ebp and %esp.

Thank you.  Thank you.  Thank you.  Did I say thank you?

> One of the reasons people would tend not to notice if %ebp and %esp
> are misnumbered in STABS is that they almost never occur.  Dwarf 2
> emits explicit location expressions to specify the "frame base" for a
> function; these expressions usually refer to %esp or %ebp.  In STABS,
> however, stack-based variables are simply marked as "LSYMS" or
> "PSYMS", whose locations are given as offsets relative to some
> implicit base that the debugger just has to know.

I expected as much since I never saw a problem in Cygwin before I tried to
add DWARF 2 support.  I just didn't know how these functions were used
well enough to find a simple test case.

> So the only way to get those register numbers to appear at all is to
> get a variable allocated to them.  You'll never get a variable
> allocated to %esp.  And you'll never get a varable allocated to %ebp
> unless you compile with -fomit-frame-pointer.  So, if I compile the
> attached program with GCC 3.3 passing -O -fomit-frame-pointer, 'n'
> gets allocated to %ebp.

FWIW, this does show the problem clearly on Cygwin.

ford@fordpc ~
$ gcc -g -O -fomit-frame-pointer frameless.c -o frameless_stab.exe

ford@fordpc ~
$ gdb frameless_stab.exe
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) b foo
Breakpoint 1 at 0x401050: file frameless.c, line 6.
(gdb) r 2
Starting program: /home/ford/frameless_stab.exe 2

Breakpoint 1, foo (n=0) at frameless.c:6
6       {
(gdb) n
8         register int a = n * 1;
(gdb) info address n
Symbol "n" is a variable in register esp.
(gdb) p n
$1 = 2289692
(gdb) p $esp
$2 = (void *) 0x22f01c
(gdb) p $ebp
$3 = (void *) 0x2
(gdb)

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

I'm getting a bit lost, so let me try to sum up the discussion, for my
own sake.  There are two distinct questions at hand:

- Should GDB's i386_stab_reg_to_regnum be changed?
- What register numbering should Cygwin Dwarf 2 use?


For the first question: I think your original patch is correct.  The
big question is, "Why wasn't it noticed before?" but there's an answer
to that which seems pretty solid to me:

- GCC's dbx_register_map and GDB's i386_stab_reg_to_regnum simply
  aren't used on many modern systems.  Every ELF target that I see in
  GCC (except for i[34567]86-*-nto-qnx*) uses gcc/config/i386/i386.c's
  svr4_dbx_register_map.  That agrees with i386-tdep.c's
  i386_dwarf_reg_to_regnum.  In GDB, we have:

    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);
    }

  and i386_elf_init_abi is called by:

    - i386fbsd-tdep.c (i386fbsd_init_abi)
    - i386gnu-tdep.c (i386gnu_init_abi)
    - i386-linux-tdep.c (i386_linux_init_abi)
    - i386nbsd-tdep.c (i386nbsdelf_init_abi)
    - i386-nto-tdep.c (i386nto_init_abi)
    - i386obsd-tdep.c (i386obsd_elf_init_abi)
    - i386-tdep.c (i386_svr4_init_abi)

  So just about every ELF target uses gdb/i386.c's
  i386_dwarf_reg_to_regnum for both STABS and Dwarf 2.  So they never
  see the broken numbering.
  
- The remain non-ELF tagrets are mostly non-Dwarf 2, and thus mostly
  STABS.  And my message to Eli Zaretskii explains why %ebp / %esp
  discrepancies won't often show up in STABS.

The bit-twiddling is correct, but I'd rather see something more
direct, like:

Index: gdb/i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.182
diff -c -c -F'^(' -r1.182 i386-tdep.c
*** gdb/i386-tdep.c	1 Apr 2004 18:14:03 -0000	1.182
--- gdb/i386-tdep.c	5 Apr 2004 22:15:01 -0000
***************
*** 211,218 ****
    /* This implements what GCC calls the "default" register map.  */
    if (reg >= 0 && reg <= 7)
      {
!       /* General-purpose registers.  */
!       return reg;
      }
    else if (reg >= 12 && reg <= 19)
      {
--- 211,223 ----
    /* This implements what GCC calls the "default" register map.  */
    if (reg >= 0 && reg <= 7)
      {
!       /* General-purpose registers.  The debug info calls %ebp
!          register 4, and %esp register 5.  */
!       if (reg == 4)
!         return 5;
!       else if (reg == 5)
!         return 4;
!       else return reg;
      }
    else if (reg >= 12 && reg <= 19)
      {


For the second question, about what register numbering to use in
Cygwin Dwarf 2:

We agree that there are no toolchains, other than the one we're
putting together right now, that uses Dwarf 2 in PE, right?  So we
could choose any numbering we please without introducing
incompatibilities with any existing toolchain.  I'm not talking about
what would be most consistent yet; I'm just observing that we wouldn't
misread any prior existing compiler's output, or misdirect any prior
existing debugger.

So what would b the most consistent numbering to use?  It's been said
that "Dwarf 2 uses svr4_dbx_register_map."  This is true, but it's
incomplete.  The big picture, I think, is this:

- GCC doesn't switch register numberings depending on the debug format
  in use (except on rs6000).  For a given GCC, -gstabs+ and -gdwarf-2
  use the same numberings.

- Dwarf 2 is mostly widely used on ELF systems, which almost all use
  svr4_dbx_register_map --- for both STABS and Dwarf 2.

The statement "Dwarf 2 uses svr4_dbx_register_map" suggests that there
would be targets that use svr4_dbx_register_map with Dwarf 2, but a
different map for other debug formats.  But that's the exception (the
rs6000), not the rule.  In fact, it looks to me as if DJGPP uses
dbx_register_map for both STABS and Dwarf 2.  (Eli, is this right?)


It's true that the comments for svr4_dbx_register_map in
gcc/config/i386/i386.c say:

  /* Define the register numbers to be used in Dwarf debugging information.

but this comment doesn't match the code it accompanies: every i386 GCC
configuration uses either dbx_register_map or svr4_dbx_register_map
for both debug formats.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Sat, 3 Apr 2004, Eli Zaretskii wrote:

> On Fri, 2 Apr 2004, Brian Ford wrote:
>
> > Ok, I'm trying to find a simple step-by-step.
>
> Thank you.

Jim beat me to it.

> > As a quick test, does a simple "bt" for a DWARF 2 compiled program stop at
> > main, or run off infinately?
>
> It stops at main.  Here's a session transcript, using the test
> program from the message you referred to:

I realized this morning that this problem only happens in DWARF 2 if your
ebp and esp are reversed.  DJGPP's are ok in DWARF 2, just not in stabs.
 See Jim's example and my response for how to test that.  Thanks for
testing anyway.

> > Can you try Jim's example program here compiled for DWARF 2?

and STABS?

> > http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html
> >
> > Try an info address a in foo and see what you get.
>
> I get the following, no matter whether I compile with "-gstabs+" or
> "-gdwarf-2":
>
> (gdb) info address a
> Symbol "a" is a variable in register st4.

I'm sorry, but are you sure you get the same register number in both
cases?  I don't see how that can be given my current understanding of the
issues.

> > Also, can you confirm the dumped DWARF info has a DW_AT_frame_base of
> > DW_OP_reg4, not 5?

Please check it for foo and main if you do this.

> I cannot use readelf here, since DJGPP binaries are COFF files, not
> ELF files.  Is there a way to do this using objdump?

No, see Jim's reply.

I do have a hacked version of dwarfdump that works on COFF files.  Let me
know if you are interested and would trust me to send you the executable
directly.

> > How often does DJGPP use sdb, stabs, dwarf 2?
>
> I don't have statistics (but see below).  I myself use all of them
> roughly the same.

Yeah, I just meant relatively.

> > I just realized that DWARF 2 is not the default.
>
> Well, it is in DJGPP: GCC 3.2 and later use DWARF-2 by default.  So I
> guess, for the random DJGPP user, DWARF-2 is much more frequent these
> days that either -gstabs+ or -gcoff.

I'm confused here.  I just did another pass through the gcc sources
(3.4 branch in this case) and looked at all the djgpp config files:
ford@fordpc ~/downloads/gcc/gcc/config

$ fgrep DEBUGGING i386/xm-djgpp.h i386/i386.h dbxcoff.h i386/unix.h
i386/bsd.h i386/gas.h i386/djgpp.h
dbxcoff.h:#define DBX_DEBUGGING_INFO 1
dbxcoff.h:#ifndef PREFERRED_DEBUGGING_TYPE
dbxcoff.h:#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG
i386/gas.h:#define SDB_DEBUGGING_INFO 1
i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1

That makes it appear that the default debugging type is SDB_DEBUG (coff).
I've got to be missing something obvious here?

Thanks again for your time.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Mon, 5 Apr 2004, Jim Blandy wrote:

> I'm getting a bit lost,

Me too ;-).

> so let me try to sum up the discussion, for my
> own sake.  There are two distinct questions at hand:
>
> - Should GDB's i386_stab_reg_to_regnum be changed?
> - What register numbering should Cygwin Dwarf 2 use?

And one tangential one:

 - Is DJGPP using the correct _to_regnum function for DWARF 2?

> For the first question: I think your original patch is correct.

Me too ;-).

> The big question is, "Why wasn't it noticed before?" but there's an
> answer to that which seems pretty solid to me:
>
> - GCC's dbx_register_map and GDB's i386_stab_reg_to_regnum simply
>   aren't used on many modern systems.  Every ELF target that I see in
>   GCC (except for i[34567]86-*-nto-qnx*) uses gcc/config/i386/i386.c's
>   svr4_dbx_register_map.  That agrees with i386-tdep.c's
>   i386_dwarf_reg_to_regnum.
[snip]
>   So just about every ELF target uses gdb/i386.c's
>   i386_dwarf_reg_to_regnum for both STABS and Dwarf 2.  So they never
>   see the broken numbering.

Agreed.  I still propose we rename the _to_regnum functions, replacing
stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy to
make a patch :-).

> - The remain non-ELF tagrets are mostly non-Dwarf 2, and thus mostly
>   STABS.  And my message to Eli Zaretskii explains why %ebp / %esp
>   discrepancies won't often show up in STABS.

That was the part I had a gut feeling about, but couldn't explain.
Thanks for the help.

> The bit-twiddling is correct, but I'd rather see something more
> direct, like:
[snip]

Ok.

> For the second question, about what register numbering to use in
> Cygwin Dwarf 2:
>
> We agree that there are no toolchains, other than the one we're
> putting together right now, that uses Dwarf 2 in PE, right?
> So we could choose any numbering we please without introducing
> incompatibilities with any existing toolchain.  I'm not talking about
> what would be most consistent yet; I'm just observing that we wouldn't
> misread any prior existing compiler's output, or misdirect any prior
> existing debugger.

To my *very* limited knowledge, yes.

> So what would b the most consistent numbering to use?  It's been said
> that "Dwarf 2 uses svr4_dbx_register_map."  This is true, but it's
> incomplete.

True except for DJGPP?

> The big picture, I think, is this:
>
> - GCC doesn't switch register numberings depending on the debug format
>   in use (except on rs6000).  For a given GCC, -gstabs+ and -gdwarf-2
>   use the same numberings.
>
> - Dwarf 2 is mostly widely used on ELF systems, which almost all use
>   svr4_dbx_register_map --- for both STABS and Dwarf 2.
>
> The statement "Dwarf 2 uses svr4_dbx_register_map" suggests that there
> would be targets that use svr4_dbx_register_map with Dwarf 2, but a
> different map for other debug formats.  But that's the exception (the
> rs6000), not the rule.  In fact, it looks to me as if DJGPP uses
> dbx_register_map for both STABS and Dwarf 2.  (Eli, is this right?)

It looks like that to me too.  But, if that were the case, and the backend
had not coded around these bugs, I don't see how it could be working.
That is why we are stuck in these tangential DJGPP ramblings.

> It's true that the comments for svr4_dbx_register_map in

Just svr4_register_map (so noone gets confused).

> gcc/config/i386/i386.c say:
>
>   /* Define the register numbers to be used in Dwarf debugging information.
>
> but this comment doesn't match the code it accompanies: every i386 GCC
> configuration uses either dbx_register_map or svr4_dbx_register_map
> for both debug formats.

Agreed.  I'm happy to stick with dbx_register_map on Cygwin for all debug
formats if a version of my patch is accepted.  DWARF 2 (and STABS) will
work fine then.  And, I'd be glad to help Eli sort through the
ramifications, since his is just about the only target to be affected.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> On Mon, 5 Apr 2004, Jim Blandy wrote:
> > For the first question: I think your original patch is correct.
> 
> Me too ;-).
> 
> ... I still propose we rename the _to_regnum functions, replacing
> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy to
> make a patch :-).

I agree that would be better.

(I should make it clear that I can't approve this patch.  We need Mark
Kettenis's okay.)

> > For the second question, about what register numbering to use in
> > Cygwin Dwarf 2:
> >
> > We agree that there are no toolchains, other than the one we're
> > putting together right now, that uses Dwarf 2 in PE, right?
> > So we could choose any numbering we please without introducing
> > incompatibilities with any existing toolchain.  I'm not talking about
> > what would be most consistent yet; I'm just observing that we wouldn't
> > misread any prior existing compiler's output, or misdirect any prior
> > existing debugger.
> 
> To my *very* limited knowledge, yes.
> 
> > So what would b the most consistent numbering to use?  It's been said
> > that "Dwarf 2 uses svr4_dbx_register_map."  This is true, but it's
> > incomplete.
> 
> True except for DJGPP?
> 
> > The big picture, I think, is this:
> >
> > - GCC doesn't switch register numberings depending on the debug format
> >   in use (except on rs6000).  For a given GCC, -gstabs+ and -gdwarf-2
> >   use the same numberings.
> >
> > - Dwarf 2 is mostly widely used on ELF systems, which almost all use
> >   svr4_dbx_register_map --- for both STABS and Dwarf 2.
> >
> > The statement "Dwarf 2 uses svr4_dbx_register_map" suggests that there
> > would be targets that use svr4_dbx_register_map with Dwarf 2, but a
> > different map for other debug formats.  But that's the exception (the
> > rs6000), not the rule.  In fact, it looks to me as if DJGPP uses
> > dbx_register_map for both STABS and Dwarf 2.  (Eli, is this right?)
> 
> It looks like that to me too.  But, if that were the case, and the backend
> had not coded around these bugs, I don't see how it could be working.
> That is why we are stuck in these tangential DJGPP ramblings.

Right.  I'm really wondering how DJGPP Dwarf 2 works at this point.

> > It's true that the comments for svr4_dbx_register_map in
> 
> Just svr4_register_map (so noone gets confused).

Really?  I'm looking at revision 1.660 of gcc/config/i386/i386.c, like
657:

int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =

Not to be "back-atcha" or anything like that; this is just such a maze
of twisty little...

> > gcc/config/i386/i386.c say:
> >
> >   /* Define the register numbers to be used in Dwarf debugging information.
> >
> > but this comment doesn't match the code it accompanies: every i386 GCC
> > configuration uses either dbx_register_map or svr4_dbx_register_map
> > for both debug formats.
> 
> Agreed.  I'm happy to stick with dbx_register_map on Cygwin for all debug
> formats if a version of my patch is accepted.  DWARF 2 (and STABS) will
> work fine then.  And, I'd be glad to help Eli sort through the
> ramifications, since his is just about the only target to be affected.

Sounds great.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Mon, 5 Apr 2004, Jim Blandy wrote:

> Brian Ford writes:
> > ... I still propose we rename the _to_regnum functions, replacing
> > stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy to
> > make a patch :-).
>
> I agree that would be better.
>
> (I should make it clear that I can't approve this patch.  We need Mark
> Kettenis's okay.)

Ok, I'll submit a patch after this thread is resolved.

> > On Mon, 5 Apr 2004, Jim Blandy wrote:
> > > It's true that the comments for svr4_dbx_register_map in
> >
> > Just svr4_register_map (so noone gets confused).
>
> Really?  I'm looking at revision 1.660 of gcc/config/i386/i386.c, like
> 657:
>
> int const svr4_dbx_register_map[FIRST_PSEUDO_REGISTER] =
>
> Not to be "back-atcha" or anything like that; this is just such a maze
> of twisty little...

You are correct.  I guess I was just having an off day and I got it stuck
in my head wrong.

> > > ... every i386 GCC configuration uses either dbx_register_map or
> > > svr4_dbx_register_map for both debug formats.
> >
> > Agreed.  I'm happy to stick with dbx_register_map on Cygwin for all debug
> > formats if a version of my patch is accepted.  DWARF 2 (and STABS) will
> > work fine then.  And, I'd be glad to help Eli sort through the
> > ramifications, since his is just about the only target to be affected.
>
> Sounds great.

Now we just need some words from Eli and an approval for your version of
my patch, I think.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 05 Apr 2004 17:44:14 -0500

   I'm getting a bit lost, so let me try to sum up the discussion, for my
   own sake.  There are two distinct questions at hand:

   - Should GDB's i386_stab_reg_to_regnum be changed?

   For the first question: I think your original patch is correct.

Yup. I agree.  I wonder whether I introduced the bug or that it has
always been wrong...

   The bit-twiddling is correct, but I'd rather see something more
   direct, like:

   Index: gdb/i386-tdep.c
   ===================================================================
   RCS file: /cvs/src/src/gdb/i386-tdep.c,v
   retrieving revision 1.182
   diff -c -c -F'^(' -r1.182 i386-tdep.c
   *** gdb/i386-tdep.c	1 Apr 2004 18:14:03 -0000	1.182
   --- gdb/i386-tdep.c	5 Apr 2004 22:15:01 -0000
   ***************
   *** 211,218 ****
       /* This implements what GCC calls the "default" register map.  */
       if (reg >= 0 && reg <= 7)
	 {
   !       /* General-purpose registers.  */
   !       return reg;
	 }
       else if (reg >= 12 && reg <= 19)
	 {
   --- 211,223 ----
       /* This implements what GCC calls the "default" register map.  */
       if (reg >= 0 && reg <= 7)
	 {
   !       /* General-purpose registers.  The debug info calls %ebp
   !          register 4, and %esp register 5.  */
   !       if (reg == 4)
   !         return 5;
   !       else if (reg == 5)
   !         return 4;
   !       else return reg;
	 }
       else if (reg >= 12 && reg <= 19)
	 {

Jim, please apply this patch, with the proper ChangeLog of course.

Mark

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Mark Kettenis]

   Date: Mon, 5 Apr 2004 18:19:09 -0500 (CDT)
   From: Brian Ford <ford@vss.fsi.com>

   > The big question is, "Why wasn't it noticed before?" but there's an
   > answer to that which seems pretty solid to me:
   >
   > - GCC's dbx_register_map and GDB's i386_stab_reg_to_regnum simply
   >   aren't used on many modern systems.  Every ELF target that I see in
   >   GCC (except for i[34567]86-*-nto-qnx*) uses gcc/config/i386/i386.c's
   >   svr4_dbx_register_map.  That agrees with i386-tdep.c's
   >   i386_dwarf_reg_to_regnum.
   [snip]
   >   So just about every ELF target uses gdb/i386.c's
   >   i386_dwarf_reg_to_regnum for both STABS and Dwarf 2.  So they never
   >   see the broken numbering.

   Agreed.  I still propose we rename the _to_regnum functions, replacing
   stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy to
   make a patch :-).

Please do so.

Mark

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Brian Ford]

On Wed, 7 Apr 2004, Mark Kettenis wrote:

> Brian Ford wrote:
>
>> I still propose we rename the _to_regnum functions, replacing
>> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy
>> to make a patch :-).
>
> Please do so.

Ok, I'm working this up and fixing all the misleading comments.  I do have
a stupid style question, though.  This bugs me:

if (a)
  return x;
else if (b)
  return y;
else
  return z;

Can that simply be:

if (a)
  return x;

if (b)
  return y;

return z;

?  I can't find any mention of this in the GNU coding standards.

Thanks.

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

Mark Kettenis <kettenis@chello.nl> writes:
> Jim, please apply this patch, with the proper ChangeLog of course.

Committed, thanks.

2004-04-07  Jim Blandy  <jimb@redhat.com>

	* i386-tdep.c (i386_stab_reg_to_regnum): Correct numbering for
	%esp and %ebp

Index: gdb/i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.182
diff -c -r1.182 i386-tdep.c
*** gdb/i386-tdep.c	1 Apr 2004 18:14:03 -0000	1.182
--- gdb/i386-tdep.c	7 Apr 2004 16:42:08 -0000
***************
*** 211,218 ****
    /* This implements what GCC calls the "default" register map.  */
    if (reg >= 0 && reg <= 7)
      {
!       /* General-purpose registers.  */
!       return reg;
      }
    else if (reg >= 12 && reg <= 19)
      {
--- 211,223 ----
    /* This implements what GCC calls the "default" register map.  */
    if (reg >= 0 && reg <= 7)
      {
!       /* General-purpose registers.  The debug info calls %ebp
!          register 4, and %esp register 5.  */
!       if (reg == 4)
!         return 5;
!       else if (reg == 5)
!         return 4;
!       else return reg;
      }
    else if (reg >= 12 && reg <= 19)
      {

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> On Wed, 7 Apr 2004, Mark Kettenis wrote:
> 
> > Brian Ford wrote:
> >
> >> I still propose we rename the _to_regnum functions, replacing
> >> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy
> >> to make a patch :-).
> >
> > Please do so.
> 
> Ok, I'm working this up and fixing all the misleading comments.  I do have
> a stupid style question, though.  This bugs me:
> 
> if (a)
>   return x;
> else if (b)
>   return y;
> else
>   return z;
> 
> Can that simply be:
> 
> if (a)
>   return x;
> 
> if (b)
>   return y;
> 
> return z;
> 
> ?  I can't find any mention of this in the GNU coding standards.

I think either way is fine.  :)

GDB has a pretty extensive set of style conformance tests
(gdb_ari.sh), but I don't think they care about the issue you mention.

[PATCH] Rename i386_xxx_reg_to_regnum

[Brian Ford]

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

On Wed, 7 Apr 2004, Mark Kettenis wrote:

> Brian Ford wrote:
>
>> I still propose we rename the _to_regnum functions, replacing
>> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy
>> to make a patch :-).
>
> Please do so.

Here is the semi-pre-approved rename patch.  I decided not to make any
style changes.

Jim, I hope you don't mind me putting words in your mouth, but I felt
your FIXME comment needed correction as a result of this, and the previous
change.

2004-04-07  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.

-- 
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.183
diff -u -p -r1.183 i386-tdep.c
--- i386-tdep.c	7 Apr 2004 16:45:45 -0000	1.183
+++ i386-tdep.c	7 Apr 2004 19:52:01 -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.  */
@@ -1808,8 +1772,8 @@ i386_go32_pc_in_sigtramp (CORE_ADDR pc, 
 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).  */
@@ -2001,13 +1965,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: jimb/2004-04-07: 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.  */

Re: [PATCH] Rename i386_xxx_reg_to_regnum

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> writes:
> On Wed, 7 Apr 2004, Mark Kettenis wrote:
> 
> > Brian Ford wrote:
> >
> >> I still propose we rename the _to_regnum functions, replacing
> >> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy
> >> to make a patch :-).
> >
> > Please do so.
> 
> Here is the semi-pre-approved rename patch.  I decided not to make any
> style changes.
> 
> Jim, I hope you don't mind me putting words in your mouth, but I felt
> your FIXME comment needed correction as a result of this, and the previous
> change.

Just change 'jimb' to 'ford', re-use whatever text you want, and make
sure it really says what *you* want it to say; that's fine.

> 2004-04-07  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.

If you're trying to match the names in gcc/config/i386/i386.c,
shouldn't the second one be called i386_svr4_dbx_reg_to_regnum?

Otherwise, looks good to me.

Re: [PATCH] Rename i386_xxx_reg_to_regnum

[Brian Ford]

On Wed, 7 Apr 2004, Jim Blandy wrote:

> Brian Ford writes:
> > On Wed, 7 Apr 2004, Mark Kettenis wrote:
> > > Brian Ford wrote:
> > >> I still propose we rename the _to_regnum functions, replacing
> > >> stabs and dwarf with dbx and svr4 to reduce confusion.  I'll be happy
> > >> to make a patch :-).
> > >
> > > Please do so.
> >
> > Here is the semi-pre-approved rename patch.  I decided not to make any
> > style changes.
> >
> > Jim, I hope you don't mind me putting words in your mouth, but I felt
> > your FIXME comment needed correction as a result of this, and the previous
> > change.
>
> Just change 'jimb' to 'ford', re-use whatever text you want, and make
> sure it really says what *you* want it to say; that's fine.

Ok.  Do I really need to supply a new patch to do that?  Or, can
whoever approves and commits it just do that please?  And, it does say
what I wanted it to ;-).

> > 2004-04-07  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.
>
> If you're trying to match the names in gcc/config/i386/i386.c,
> shouldn't the second one be called i386_svr4_dbx_reg_to_regnum?

I dunno.  I think that might be more confusing.  It's explicit in the
comment anyway, and I didn't want to be redundant.

I'd prefer to just leave it, but if someone else feels strongly, feel free
to change it on commit.

> Otherwise, looks good to me.

Thanks for the vote of confidence.

Let me know if I need to generate a new patch with the two changes above.
Call me lazy ;-).

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

Re: [PATCH] Rename i386_xxx_reg_to_regnum

[Jim Blandy]

Brian Ford <ford@vss.fsi.com> 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. :)

Re: [PATCH] Rename i386_xxx_reg_to_regnum

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 07 Apr 2004 16:39:29 -0500

   Brian Ford <ford@vss.fsi.com> 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.

Mark

Re: [PATCH] Rename i386_xxx_reg_to_regnum

[Brian Ford]

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

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Tue, 6 Apr 2004 09:53:38 -0500 (CDT)
> From: Brian Ford <ford@vss.fsi.com>
> 
> Now we just need some words from Eli and an approval for your version of
> my patch, I think.

Sorry, I was away of my email for a few days, and am now facing a huge
backlog.  Please give me a couple of days to study this thread and the
relevant code and respond.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Mon, 5 Apr 2004 16:57:46 -0500 (CDT)
> From: Brian Ford <ford@vss.fsi.com>
> 
> > So the only way to get those register numbers to appear at all is to
> > get a variable allocated to them.  You'll never get a variable
> > allocated to %esp.  And you'll never get a varable allocated to %ebp
> > unless you compile with -fomit-frame-pointer.  So, if I compile the
> > attached program with GCC 3.3 passing -O -fomit-frame-pointer, 'n'
> > gets allocated to %ebp.
> 
> FWIW, this does show the problem clearly on Cygwin.
> 
> ford@fordpc ~
> $ gcc -g -O -fomit-frame-pointer frameless.c -o frameless_stab.exe
> 
> ford@fordpc ~
> $ gdb frameless_stab.exe
> [...]
> (gdb) info address n
> Symbol "n" is a variable in register esp.
> (gdb) p n
> $1 = 2289692

I see a similar bug in frameless.c compiled with the DJGPP port of GCC
using -gstabs+.  So indeed the bug uncovered by Brian exists in DJGPP
as well, and the patch for stabs register renumbering will fix it for
DJGPP.  Thanks!

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> From: Jim Blandy <jimb@redhat.com>
> Date: 05 Apr 2004 17:44:14 -0500
> 
> In fact, it looks to me as if DJGPP uses dbx_register_map for both
> STABS and Dwarf 2.  (Eli, is this right?)

No, that's not what I see.  The file /config/i386/djgpp.h in the GCC
distribution says:

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

(This is from GCC 3.3.3 source distribution I find in the DJGPP
repository.)

So DJGPP uses svr4_dbx_register_map[] for DWARF-2, dbx_register_map[]
otherwise.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> Date: Mon, 5 Apr 2004 17:46:09 -0500 (CDT)
> From: Brian Ford <ford@vss.fsi.com>
> 
> > > I just realized that DWARF 2 is not the default.
> >
> > Well, it is in DJGPP: GCC 3.2 and later use DWARF-2 by default.  So I
> > guess, for the random DJGPP user, DWARF-2 is much more frequent these
> > days that either -gstabs+ or -gcoff.
> 
> I'm confused here.  I just did another pass through the gcc sources
> (3.4 branch in this case) and looked at all the djgpp config files:
> ford@fordpc ~/downloads/gcc/gcc/config
> 
> $ fgrep DEBUGGING i386/xm-djgpp.h i386/i386.h dbxcoff.h i386/unix.h
> i386/bsd.h i386/gas.h i386/djgpp.h
> dbxcoff.h:#define DBX_DEBUGGING_INFO 1
> dbxcoff.h:#ifndef PREFERRED_DEBUGGING_TYPE
> dbxcoff.h:#define PREFERRED_DEBUGGING_TYPE SDB_DEBUG
> i386/gas.h:#define SDB_DEBUGGING_INFO 1
> i386/djgpp.h:#define DWARF2_DEBUGGING_INFO 1

i386/djgpp.h in the GCC 3.3.3 distribution I have says:

    /* Support generation of DWARF2 debugging info.  */
    #define DWARF2_DEBUGGING_INFO 1

    /* Use DWARF2 debugging info by default: comment out following  */
    /* 2 lines to default to COFF debugging info  */
    #undef PREFERRED_DEBUGGING_TYPE
    #define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG

So the preferred debug info is DWARF-2.

It sounds like the person who ports GCC for DJGPP edits djgpp.h before
building, because the official GCC tarball on ftp.gnu.org doesn't
redefine PREFERRED_DEBUGGING_TYPE (and neither does it define register
renumbering I cited in the previous mail, in response to Jim's
question).  This could explain why you are confused.

ix86 PE/COFF DWARF register numbering (was Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp))

[Brian Ford]

On Sun, 18 Apr 2004, Eli Zaretskii wrote:

> On 05 Apr 2004 at 17:44:14 -0500 Jim Blandy wrote:
> >
> > In fact, it looks to me as if DJGPP uses dbx_register_map for both
> > STABS and Dwarf 2.  (Eli, is this right?)
>
> No, that's not what I see.  The file /config/i386/djgpp.h in the GCC
> distribution says:
>
>     #undef DBX_REGISTER_NUMBER
>     #define DBX_REGISTER_NUMBER(n) \
>       ((write_symbols == DWARF2_DEBUG) ? svr4_dbx_register_map[n] : dbx_register_map[n])

Aha!

> (This is from GCC 3.3.3 source distribution I find in the DJGPP
> repository.)

(We see in a later email that this distribution contains local patches
which have not been included in the FSF source base.  That explains the
previous confusion.)

> So DJGPP uses svr4_dbx_register_map[] for DWARF-2, dbx_register_map[]
> otherwise.

Look Jim (does this sound like a bad Star Trek episode, or what? :), yet
another target that uses a different register map depending on the output
debugging format.  And note that for DWARF 2, it uses the svr4 map, just
like every other ix86 target that I know of (except the current PE
proposal).

Now that the dbx_to_regnum bug has been fixed, it probably doesn't
matter, but I'm still leary of using a different register map for DWARF on
PE than every other ix86 target out there.  I'd like to get this right up
front since now is the time to avoid possibly major compatibility
changes down the road.

What do you think?  Should I revert the i386_coff_init_abi patch for
Cygwin and use the above method in gcc instead?  I'm especially interested
in input from Jim Blandy, CGF, and Corinna.

Thanks.

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

Re: ix86 PE/COFF DWARF register numbering (was Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp))

[Eli Zaretskii]

> Date: Sun, 18 Apr 2004 21:06:37 -0500 (CDT)
> From: Brian Ford <ford@vss.fsi.com>
> 
> And note that for DWARF 2, [DJGPP] uses the svr4 map, just like every
> other ix86 target that I know of (except the current PE proposal).

This was done at Mark Kettenis's suggestion, back in 2001, as you
will see in the thread I cited a few days ago.  In the DJGPP project,
we simply took that suggestion and implemented it in GCC when DWARF-2
support for DJGPP was first added to GCC.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Eli Zaretskii]

> > 
> > So DJGPP uses svr4_dbx_register_map[] for DWARF-2, dbx_register_map[]
> > otherwise.
> 
> Okay.  That text is not present in the public GCC sources, or in the
> GCC 3.3 release's sources.  (I *thought* I had looked carefully for
> such things.)  Is this a change that needs to be pushed upstream?

Yes, I think so.  I already asked the person who works on the DJGPP
port of GCC to do that, so perhaps it will be done RSN.

Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

[Jim Blandy]

"Eli Zaretskii" <eliz@gnu.org> writes:

> > From: Jim Blandy <jimb@redhat.com>
> > Date: 05 Apr 2004 17:44:14 -0500
> > 
> > In fact, it looks to me as if DJGPP uses dbx_register_map for both
> > STABS and Dwarf 2.  (Eli, is this right?)
> 
> No, that's not what I see.  The file /config/i386/djgpp.h in the GCC
> distribution says:
> 
>     #undef DBX_REGISTER_NUMBER
>     #define DBX_REGISTER_NUMBER(n) \
>       ((write_symbols == DWARF2_DEBUG) ? svr4_dbx_register_map[n] : dbx_register_map[n])
> 
> (This is from GCC 3.3.3 source distribution I find in the DJGPP
> repository.)
> 
> So DJGPP uses svr4_dbx_register_map[] for DWARF-2, dbx_register_map[]
> otherwise.

Okay.  That text is not present in the public GCC sources, or in the
GCC 3.3 release's sources.  (I *thought* I had looked carefully for
such things.)  Is this a change that needs to be pushed upstream?

Re: ix86 PE/COFF DWARF register numbering

[Brian Ford]

On Mon, 19 Apr 2004, Eli Zaretskii wrote:

> On Sun, 18 Apr 2004 at 21:06:37 -0500 (CDT) Brian Ford wrote:
>
> > And note that for DWARF 2, [DJGPP] uses the svr4 map, just like every
> > other ix86 target I know of (except the current PE proposal).
>
> This was done at Mark Kettenis's suggestion, back in 2001, as you
> will see in the thread I cited a few days ago.

Yes, I saw that suggestion here:

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

and commented on it here:

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

> In the DJGPP project, we simply took that suggestion and implemented it
> in GCC when DWARF-2 support for DJGPP was first added to GCC.

but there was no follow-up that stated which of the two possible
suggestions were chosen.  Taking together FSF GCC sources and GDB sources
showed the issue was still unresolved.

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