This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]