To be more specific, here is my target device spec:
Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 119.19 Features : swp half thumb
fastmult edsp java
CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part :
0x926 CPU revision : 5
So i tried your suggestion, which is "Delete the -mcpu entirely". Another error
pops up:
m_dispatch/dispatch-arm-linux.S: Assembler messages:
m_dispatch/dispatch-arm-linux.S:157: Error: constant expression required --
`movw r1,#:lower16:vgPlain_stats__n_xindirs_32'
m_dispatch/dispatch-arm-linux.S:158: Error: constant expression required -- `movt r1,#:upper16:vgPlain_stats__n_xindirs_32'
m_dispatch/dispatch-arm-linux.S:166: Error: constant expression required -- `movw r4,#:lower16:vgPlain_tt_fast'
m_dispatch/dispatch-arm-linux.S:169: Error: constant expression required --
`movt r4,#:upper16:vgPlain_tt_fast'
m_dispatch/dispatch-arm-linux.S:182: Error: constant expression required --
`movw r1,#:lower16:vgPlain_stats__n_xindir_misses_32'
m_dispatch/dispatch-arm-linux.S:183: Error: constant expression required --
`movt r1,#:upper16:vgPlain_stats__n_xindir_misses_32'
Makefile:3224: recipe for target
'm_dispatch/libcoregrind_arm_linux_a-dispatch-arm-linux.o' failed
0. Running valgrind on Fedora or Debian on a RaspberryPi-3B is so easy and
inexpensive
that the app must not be portable. Perhaps it is tied to some special hardware
that
is available only on the board with your ARM926EJ-S rev 5 (v5l) ? Why not run
on
armv7*, using the software model that simulates the device?
Remember: memcheck is 40 to 50 times slower than straight execution
(the 926EJ has small and slow caches),
so if the device has any hard timing constraints then you may be out of luck;
but often you can change the timing constraints in a software model.
Why not manipulate the device on the 936EJ over the network from the
RaspberryPi?
Use what the hardware hackers did to develop the device and/or its software
driver.
1. Because the 926EJ is armv5l, then it doesn't do threads very well. Valgrind
assumes that threads work well, so if the app uses threads then you will fail
if you try to run memcheck on the 926EJ. Get armv7*.
2. Looking at the code, the first 2 and last 2 complaints from the assembler
refer to blocks like:
/* stats only */
movw r1, #:lower16:vgPlain_stats__n_xindirs_32
movt r1, #:upper16:vgPlain_stats__n_xindirs_32
ldr r2, [r1, #0]
add r2, r2, #1
str r2, [r1, #0]
and indeed, r1 and r2 are dead after that. So one option is to comment-out
the block of code, and remember that the statistics will be incorrect.
[But you never looked at them before.]
3. The other two complaints refer to:
/* try a fast lookup in the translation cache */
// r0 = next guest, r1,r2,r3,r4 scratch
movw r1, #VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
movw r4, #:lower16:VG_(tt_fast)
and r2, r1, r0, LSR #1 // r2 = entry #
movt r4, #:upper16:VG_(tt_fast) // r4 = &VG_(tt_fast)
which can be re-written to use an explicit pointer; something like:
ldr r4, p_tt_fast // r4 = &VG_(tt_fast)
movw r1, #VG_TT_FAST_MASK // r1 = VG_TT_FAST_MASK
and r2, r1, r0, LSR #1 // r2 = entry #
<<snip>>
b postamble
p_tt_fast:
.word VG_(tt_fast)
This will be 1 or 2 cycles slower: a couple percent overall.
--
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
