https://bugs.kde.org/show_bug.cgi?id=360008
--- Comment #9 from Philippe Waroquiers <[email protected]> --- Re-reading the comment at the beginning of valgrind-low-ppc64.c, the register maps is still not clear to me. The comment tells there are 64 VSR registers of 64 bits. But afterwards; the same commen tells that "The 32 vr[0] to vr[31] registers of size 128-bits map to VSR[31] to VSR[63].". Probably a VSR register is 128 bits. The second not very clear thing is for the fp registers: when the comment tells that 'however, these are not "real" floating point registers': is that speaking about fp[0..31] or rather about upper 64 bits of vsr[32] to vsr[63] ? I guess the later, so maybe tells something like floating point instructions are referencing the fp registers, and not the vsr registers. Finally, the last paragraph tells 'the 32 floating point registers (AKA VSR[0] to VSR[31])' which contradicts the previous paragraph that told the fp register sare in vsr[32..63] upper bits. In the code that initialises low_offset and high_offset : for VG_BIGENDIAN, the comment tells that the 64-bits are stored as Little Endian. Are the values really stored as little endian, even on a big endian platform ? The little endian comment says everything is little endian (so sounds logical); but the big endian case seems half big/half little. If this is really the case, then maybe add a sentence such as: "In the big endian case, a little endian convention is still partially used." For the xml core2 file: after re-reading the comment and playing with gdb on gcc110, I finally understood :). GDB is somewhat bizarre: it prints the general registers, then the fp register 0 .. 31, then pc etc, even if the xml file defines them in the order general registers followed by pc etc followed by fp 0 .. 31. Thanks for clarifying this. Otherwise, patch looks good to me. Up to you to see which additional updates you do for the comments above, but feel free to commit. Thanks -- You are receiving this mail because: You are watching all bug changes.
