This is the mail archive of the 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 for printing 64-bit values in i386 registers; STABS format

On Fri, Apr 25, 2003 at 10:44:37PM -0400, Andrew Cagney wrote:
> >>It's possible to fix this without adding an architecture method, or 
> >>implementing location expressions (the penny just dropped).  The basic 
> >>problem is the same as for the MIPS - need a custom register area.  Hence:
> >>
> >>- define a sequence of nameless cooked ([NUM_REGS .. 
> >>NUM_REGS+NUM_PSEUDO_REGS) range) registers ordered the way stabs would 
> >>like them
> >>- modify the existing stabs_regnum_to_regnum to map the messed up 
> >>registers onto those values
> >
> >
> >Could you explain why you think that (which I personally think is much
> >grosser, since it perpuates the assumption that values continue into
> >sequential registers) is a better solution than Mark's approach?
> The assumption that values continue into sequential registers is, 
> unfortunatly. how stabs works :-(

So?  I don't want to bind anything in GDB's design to how stabs works. 
That's gotten us in all sorts of trouble.

> The consequence of `without adding an architecture method' is that it 
> confinds the i386 case to the i386.  The MIPS case, which is far worse, 
> will also be the same (at present there is a slew of per-architecture 
> methods that can be eliminated when the MIPS switches to the same strategy).

I'm afraid I don't understand, and I still don't see your reasoning
against this approach.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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