This is the mail archive of the gdb@sourceware.cygnus.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]

Re: none



> > So, does the compiler use separate numbers in the debug for MMX
> > registers and FP stack registers, or the same numbers?
> > 
> > If the compiler uses separate register numbers, then we have the
> > problems discussed before: as far as I can tell, GDB simply isn't set
> > up to cope with the idea that certain bits might be part of two
> > registers.
> > 
> > If the compiler uses the same register numbers, how can the
> > architecture-specific code tell whether GDB is accessing MM0 (which
> > lives in R0) or ST(0) (which lives in R(TOS))?
> 
> The architecture-specific code knows about TOS, right?  It's part of
> the status word, so it's available to GDB.  Since TOS is handled the
> same by all x86 platforms, we could use the value of TOS to define two
> x86-specific functions to map between ST(i) and the corresponding MMj
> register and back.
> 
> Given these mapping functions, the code which implements the MMX view
> of the FP registers could allow both reading and writing MMX registers
> by accessing the corresponding ST(i) registers, each time using the
> current value of TOS.
> 
> Am I missing something obvious?  If so, perhaps I don't understand how
> the register views are (or would be) implemented.

For register views, yes, we can do anything we please.  However, when
the compiler places a register in an MMX register value, we still get
an old-fashioned symbol with a LOC_REGISTER.  Register views don't
come into it.  As long as we only have a LOC_REGISTER, we don't have
enough information to do the job right.

We could add a new symbol LOC type, LOC_REGISTER_VIEW, which produces
a struct value the same way a register view does.  Then, we could have
an architecture-specific hook can map certain register numbers in
debugging information onto LOC_REGISTER_VIEW, instead of LOC_REGISTER.
That might be the cleanest solution.

It remains to be seen whether I can persuade the maintainers to accept
register views at all.  They could reasonably argue that this is all
x86 hair, and should be isolated in x86 code.  And I also have the
feeling that there's something more general and cleaner we could do
here.  I'll need to think about it.

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