|
From: Crestez D. L. <cdl...@gm...> - 2015-04-01 15:40:45
|
Hello, It seems that valgrind upstream has no support for the mips n32 abi. I searched around but I found no applicable patches so I made my own. I got it to the point where it can actually run useful software (the stuff I want to debug). It does still generate lots of false positives. The N32 abi is very similar to the x32 API from the intel world. It has full 64bit registers but 32bit pointers and ints/longs. The purpose of the ABI is to take full advantage of 64bit CPUs but avoid the increased memory consumption. Address space is obviously limited but this limitation does not matter unless you have a lot of RAM. It uses 32bit elf headers (ELFCLASS32) but it can be distinguished by the EF_MIPS_ARCH_64R2 flag (which indicates 64bit code). It also has it's own syscall numbers. It is much more similar to the N64 abi than the "o32" abi for mips32 cpus. For example the o32 ABI even names registers differently. Presumably valgrind support for n32 would look similar to support for the x32 ABI, but that does not exist yet. I made this work by adding a new "mips64n32" architecture which is compiled as a secondary to mips64. In theory mips32 with the o32 ABI could be the secondary for mips64, but this is not supported yet. Eventually valgrind will need to support either "ternary" architectures (for stuff like x32) or just a list of secondary architectures. It might even be possible to run n32 code without compiling the valgrind tools again, but that would be very difficult. It seems that valgrind has a compile-time dependency on stuff like the size of the elf header, register sizes (implied in the guest machine type) and syscall numbers. I posted my current patches in bug #345763 because the attachments are too large for the mailing list. I'm using git clones for development but the patches should apply cleanly with either "svn patch" or "patch -p1". I also made my git trees public, they contain the same changes split into many smaller patches. It makes it easier to differentiate between ifdef spam and actual subtle changes: https://bugs.kde.org/show_bug.cgi?id=345763 https://github.com/cdleonard/valgrind/commits/mips64n32 https://github.com/cdleonard/valgrind-vex/commits/mips64n32 The diff is not very large. I was able to avoid most copy/pasting by making VG{A,P}_mips64n32 mostly equivalent to VG{A,P}_mips64. This looks tedious but is similar to how ppc64le is implemented. I would like to push this upstream eventually. Let me know what you think of the approach and what is required in order to get this commited. I did not run the valgrind unit tests because I am cross-compiling. I can try to run them inside a debian-mips VM if it helps. Regards, Leonard |