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

[Jim Blandy <jimb@redhat.com>]

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.