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

[Brian Ford <ford@vss.fsi.com>]

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