This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: mips-tdep.c: Unification of FPR size detection
On Wed, 19 Dec 2007, Daniel Jacobowitz wrote:
> No, that's the exact opposite of what I meant. If you don't have a
> frame available, then you have to assume the target essentially has no
> registers (yet, or any longer, or...). So we can not make any
> decisions based on their values. If you're caching the value,
> it seems suspiciously to me like guessing an arbitrary wrong value,
> maybe even from a previous session.
Well, for whatever reason a frame is commonly not available during a
debugging session -- I think it gets invalidated at some point and the
problem is in the process of being reestablished the size of the FP
registers is being determined. I can see if I can get a backtrace leading
to this scenario.
This patch in its current form assumes if no frame is available, then the
width of the registers is irrelevant and because some value has to be
provided it uses the native one.
> Right. But it doesn't change the size of the registers as presented
> by a remote stub to GDB. So, for our purposes I think the best model
> is that the size of the raw FP registers does not change. How can we
> change the size of the raw registers while the stub is sending the
> same bit patterns to GDB?
This sounds like a bug in the stub then -- probably an outcome from the
semantics of the "ldc1/sdc1" instructions which it may use rather than
exposing the actual topology of the register file. It may have worked
reasonably well for legacy MIPS processors, because odd-numbered FP
registers were only usable as a high-part of double values, so the FPU
could have been effectively treated as one having 16 64-bit FPRs split in
an original way.
It is misleading for current (MIPS rev.2) processors though as in the
32-bit FPR mode all the registers are full-featured single FPRs and also
the paired-single and fixed long type are not supported with pairs of
registers even though the double type is.
I am not sure that pretending the architecture of the FPU is different to
what it actually is is going to gain us anything.
> Something needs to change, sure, but I don't think this is it.
Any proposals then? Either way cp0.Status.FR has to be checked -- either
for the width of FPRs (64-bit vs 32-bit) as in the patch proposed or for
the number of them (32 vs 16) if the width is pretended to be always
64-bit.
Maciej