Version: (using KDE KDE 3.5.2) OS: Linux Please consider adding support for the arm(xscale) cpu architecture to enable valgrind use on mobile phones. Also, details on sponsoring such development would be useful.
ARM/Linux is also used for other embedded systems. My company has several, with serious need for a capable memory leak / analysis tool.
ARM keeps pretty strict controls on its architecture. For example, part of the license agreement for accessing the architecture specifications (which would be a necessity for porting Valgrind and VEX to ARM) is that you do not attempt to develop models of microprocessor cores based on ARM. For example, see paragraph 2 of this ARMv7-M architecture document license agreement: http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html
I don't see how this is relevant. No one is proposing "to develop models of microprocessor cores based on ARM." Surely that language just means you can't rip off the physical or logical design to make a copycat processor core. The preceding paragraph grants the right to make applications and software tools, which is all that is needed.
Unfortunately that is exactly what that language means and ARM is known to enforce it vigourously. It seems that they want nobody other than themselves to develop ARM simulators.
But if that's true, then how is it that GXemul (http://gavare.se/gxemul/) and QEMU (http://fabrice.bellard.free.fr/qemu/status.html) have both had ARM support for quite a while?
Not just those two tools, but others like SkyEye, too. I'm not a lawyer, and I've not been involved in the development of any of these tools. This means I can't tell you if what any of these developers are doing is legal. This also means that if what these developers are doing is not legal, I can't explain to you why they chose to do it. If a lawyer tells you that what they're doing is legal, it may be because they chose to emulate an earlier version of the architecture that does not have these restrictions. I have spoken with several people who have worked at ARM Ltd. at one point or another in their careers, and they have all agreed with what I have said. At my day-job, my colleagues and I work very closely with ARM devices and we would never ever consider developing an emulator because of the licensing terms. This is a personal choice, so to speak: what others decide to do with their time is their personal business.
Created attachment 28807 [details] Second submission of VG for ARM <This is what was sent to the VG mailinglist> Hi everyone <disclaimer> This is not ready for submission just yet, I just wanted to give a heads up that it's still in progress</disclaimer> Attaching version #2 of the ARM patch (First version previously submitted by Evan Geller.) Since the last patch, a condensed changelist follows: (Not being very detailed here, as the previous patch is probably not in use by anyone) * (no)Redirect calls are fixed * New syscalls supported * Bunch of IR generation issues * New instructions * Fixed clone wrapper so threads are working correctly * fixed (RT and normal) signals * restarting syscalls * Client requests work * Lots of cleanup * Pretty much all cpu dependent parts of VG is implemented. Good things: * Most small applications work as expected (ie, testcases) * Commonly used ARMv4 - ARMv7 instructions are in VEX. All code I'm testing on is compiled with gcc with armv7 target. Bad things: * VEX: Instruction translation bugs... Expect to see --tool=none mess up certain programs. ARMv4 instructions seems somewhat stable. * Helgrind, DRD and exp-ptrcheck are failing most tests, not really debugged this part. * Still using an ugly script "prebuild-native..." to build genoffsets. Anyone know enough autoconf foo how to do this correctly? * Stacktrace issues, some varinfo tests fail. There are also a few changes in platform independent code. Will try and create seperate patches for these when I'm ready to submit patches for mainline merge. The patch is based of VG rev: 8801, VEX rev: 1873 -----Test results if anyone is interested------ == 85 tests, 6 stderr failures, 1 stdout failure, 0 post failures == none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fucomip (stderr) none/tests/shell (stderr) none/tests/tls (stdout) Command exited with non-zero status 1 real 6m 43.56s user 3m 19.03s sys 1m 4.65s == 125 tests, 29 stderr failures, 6 stdout failures, 0 post failures == memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/errs1 (stderr) memcheck/tests/fprw (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/linux-capget (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/origin2-not-quite (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/origin6-fp (stderr) memcheck/tests/oset_test (stdout) memcheck/tests/oset_test (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sh-mem-random (stdout) memcheck/tests/sh-mem-random (stderr) memcheck/tests/signal2 (stdout) memcheck/tests/signal2 (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stdout) memcheck/tests/varinfo6 (stderr) memcheck/tests/vcpu_bz2 (stderr) memcheck/tests/vcpu_fbench (stdout) memcheck/tests/vcpu_fbench (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/vcpu_fnfns (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) Command exited with non-zero status 1 real 22m 54.07s user 13m 41.70s sys 2m 59.58s Running the other tools (drd, etc) are much slower, and well, I fail too many of them anyway ;)
Created attachment 28808 [details] arm port submission 2. Now without compression.
Created attachment 32347 [details] WIP of arm port Added current state of the port. Patch based of VG 9490, VEX 1888.
Created attachment 32348 [details] WIP of arm port Missed to disable VFP on the previous patch, now panics if it hits a VFP DPI.
== 383 tests, 47 stderr failures, 9 stdout failures, 1 post failure == callgrind/tests/threads (stderr) drd/tests/fp_race (stderr) drd/tests/recursive_mutex (stderr) drd/tests/rwlock_test (stderr) drd/tests/sem_as_mutex (stderr) drd/tests/tc11_XCHG (stderr) drd/tests/tc19_shadowmem (stderr) exp-ptrcheck/tests/bad_percentify (stdout) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stdout) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stdout) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc19_shadowmem (stderr) massif/tests/overloaded-new (post) memcheck/tests/fprw (stderr) memcheck/tests/linux/stack_switch (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin2-not-quite (stderr) memcheck/tests/origin3-no (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/origin6-fp (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/vcpu_fnfns (stdout) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/shell (stderr) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/tls (stdout) results from running all unit-tests with the latest patch on armv7-a no-fp hardware.
*** Bug 130830 has been marked as a duplicate of this bug. ***
This has not been forgotten about. Am expecting to progress it during 2H09.
This patch seems to work under Linux on a QEMU-lated ARM processor. However, the simplest run on the bzip2 binary fails: $ cp /bin/bzip2 bzip2 $ inst/bin/valgrind ./bzip2 ./bzip2 ... disInstr(arm): unhandled instruction: 0xE686400B vex: the `impossible' happened: armToIR: unimplemented insn vex storage: T total 134593568 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==24292== at 0x38029030: ??? (in /home/ubuntu/src/valgrind/inst/lib/valgrind/memcheck-arm-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==24292== at 0x484EF90: ??? (in /lib/libbz2.so.1.0.4) ==24292== by 0x4850837: BZ2_blockSort (in /lib/libbz2.so.1.0.4)
In progress. I expect to start pushing code into the repo, on a branch, mid/late November.
Comment on attachment 32348 [details] WIP of arm port Make this patch obsolete. There is an ARM branch in the valgrind repository that contains more recent code.
The ARM branch has been folded into the mainline source tree now, so you should be able to check out and build it using the vanilla instructions listed at http://www.valgrind.org/downloads/repository.html Note that (1) the minimum CPU requirement is something capable of the ARMv7 instruction set (Cortex-A8, for example) and (2) you need to ensure that debugging symbols for ld.so are available, else Memcheck will really not be happy. On Ubuntu 9.04 for ARM, this is done by installing the "libc6-dev" package.
Hi, Any idea, if future releases are going to support ARM Big endian (Xscale) Regards, Gyanesh
ARM has been supported since the 3.6.0 release so I think we can close this now.