Created attachment 50938 [details] Valgrind part of the patch (against r11287) Here is the patch that adds ARMv5 and v6 support to Valgrind, so it can be run on older hardware. Originally there were 3 issues preventing Valgrind from running on old boards. I. Function imm32_to_iregNo in VEX/priv/host_arm_defs.c emitted movw and movt instructions which are mandatory only on ARMv7 and optional on earlier processors. This was solved by checking processor version and using 4 mov instruction instead of movw/movt for v6 and v5. This part accidentally slipped to NEON patch and was applied recently. II. TLS value may be stored in CP15's register or at address 0xffff0ff0. The second case is handled incorrectly by Valgrind since revision r10973 in branches/ARM lately merged into trunk ( http://sourceforge.net/mailarchive/message.php?msg_name=20091229170034.6CD73108845%40jail0086.vps.exonetric.net ). This bug has little effect on v7 targets because most of them are configured to use CP15's register but always shows on v5 targets. I believe that reverting r10973 is the best way to solve this issue because: 1. There is no solid way of figuring out how is kernel configured, but it is guaranteed that function at address 0xffff0fe0 will return TLS address. So Valgrind needs to either execute both set_tls and get_tls or emulate both of them. 2. set_tls is a syscall so Valgrind cann't trace into it. 3. set_tls syscall has global side-effects which will affect state of the real thread but not of the virtual one (guest thread state). III. A swp instruction (v5) was converted to ldrex/strex (v6). The best solution is to add Ist_Swp which would be reassembled back to swp instruction. But there are so few different statements in IR that I'm not sure if it is ok to add a new one for this case only. I tried to substitute a fake comparison argument to Ist_CAS but this break IR semantics very seriously. For now I disassemble swp to non-atomic Load/Store pair for v5 targets. Comments and suggestions on this patch are welcome.
Created attachment 50939 [details] VEX part of the patch (against r2019)
I've adapted previously circulating patches for ARMv5 to work against valgrind 3.14.0. ARMv5 support is still important. Many current SoC used in embedded devices still use older cores such as ARM926EJ-S (armv5te) in combination with specialist hardware for reasons of low cost and power consumption. My patch is largely based on this patch, which you'll have to get from the Google cache as the link is now dead: http://toxygen.net/misc/valgrind-3.9.0-armv5.diff http://webcache.googleusercontent.com/search?q=cache:UV8SsZbg5ZcJ:toxygen.net/misc/valgrind-3.9.0-armv5.diff That patch in turn credits patches from bug #281975 As well as making the patch apply to 3.14.0, I had to add further changes - in particular to the hand coded asm in memcheck/mc_main{,_asm}.c This patch contains various unpleasant hacks, but it works for me so should be useful to others with ARMv5 hardware - and could form the basis of official support in the unlikely case of the team wanting to add it.
Created attachment 117327 [details] ARMv5 patch against 3.14.0
Chris - thanks for this, much appreciated - was planning on doing the same thing, and you bet me to it. Compiled and tested and works like a charm. V5 arm is still used in a significant number of products - here's hoping the dev team accept these changes.
Any chance for any of the developers to have a look at the patch to support armv5 and v6 (ie the Debian armel) architectures? It would be great if valgrind could be used on these.