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

[Brian Ford <ford at vss dot fsi dot com>]

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