This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
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.