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] |
OK, I'm going to go out on a limb here. I don't think the two are equivalent, and I think the second is wrong. For big-endian, the second would store fp[n+0] ||| fp[n+1] backwards.
No, the two are not equivalent, in terms of the memory layout that results on big endian systems. (On little-endian systems, AFAICT they end up producing the same results.)
However, neither is more correct w.r.t. what's allowed by the MIPS architecture; both will work with MIPS2 and later hardware. Doing the stores as dwords is clearly more efficient, though.
Err, I'm not sure what code you reference. I couldn't find "register_to_type" (case insensitively), anywhere in the GDB source.
is going to need, for BE, a big-byte little-word DOUBLE, and a similarINT64. Otherwize, $f0.int32 would modify the wrong part of the double register. Alternatively, some of those union values could be given magic offsets. Looking at kevin's patch:
Right. I think the "assume 4 bytes of pad before the 4-byte item" is the right way to look at it.
And then to follow on from that:
* if 32-bit FPU (32-bit MIPS or 64-bit MIPS with FR == 0), assume you have 16 of them, or
* if 64-bit FPU, you have 32.
(at least, that's the way it should work for "normal" FPU usage. For single-float, where $f0 and $f1 contain independent singles, it's another story.)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |