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

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

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