Получение valgrind для android. Проблемы с `valgrind` ищет` memcheck-arm-linux`

Question

Контекст разрабатывает приложение для Android, которое использует несколько статических исполняемых двоичных файлов через системный вызов sh. Один из двоичных файлов в конечном итоге может возникнуть при использовании мобильного телефона samsung galaxy s4 (но не при использовании эмулятора или сотового телефона Sony Xperia tipo), поэтому после http://embetek.blogspot.com.es/2011/10/valgrind-for-arm.html с несколькими пользовательскими модификациями (CFLAGS = '- static -march = armv7-a) получение

$ ldd valgrind 
not a dynamic executable 
$ file valgrind 
valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV), 
statically linked, for GNU/Linux 3.2.0, not stripped. 

Loaded на целевой телефон (версионируются андроид 4.2.2 ядро ​​3,4 ...), (context.getFilesDir() + File.separator + "valgrind").canExecute() возвращает ложь.

Бег sh -c PATH...valgrind сообщает valgrind: can't execute: Permission denied и статус 126 на выходе.

Emulator кажется запустить ядро ​​2.6 ... так что adb shell и выполнение valgrind там сказало что-то подобное, но более декорирование рассказывающего о несоответствии версии ядра: буквально

llostatic/files/valgrind              < 
FATAL: kernel too old 
Segmentation fault 

(context.getFilesDir() + File.separator + "valgrind").setExecute() не удается по неизвестной причине было (dumpAssetToFile("valgrind"){/* Many things suppressed here. */ argument.setExecute() /* Done wrong without a files dir path ask */})

Теперь valgrind, кажется, правильно призывает к memcheck-arm-linux, но я сделал это еще не признал это.

Даже исполнение "sh -c \"PATH=$PATH:" + getFilesDir() + File.separator + " " + getFilesDir() + File.separator + "busybox strace valgrind -v " + BINARY + " " + ARGS + " " + "2>&1\"" не делает то, что я ожидаю. Это не совсем то, что выполняется, но я выводил это на stderr.

W/System.err(6918): commandStrArr[0]: sh 
W/System.err(6918): commandStrArr[1]: -c 
W/System.err(6918): commandStrArr[2]: PATH=$PATH:/data/data/NAMESPACE/files/ busy 
box strace valgrind -v /data/data/NAMESPACE/files/BINARY ARGS 2>&1 
W/System.err(6918): strace: applet not found 
W/System.err(6918): valgrind: failed to start tool 'memcheck' for platform 'arm-l 
inux': No such file or directory 
W/System.err(6918): Error: BINARY exited with status nonzero (1). 

Мой чтения этого является то, что busybox не может эмулировать strace, но в любом случае выполнения в качестве команды и арг от того, что он думает, как арг [2] до конца его точки зрения аргументов. valgrind загружается хорошо, но не может найти memcheck. Контекстом здесь является memcheck-arm-linux - это актив. ed статические двоичные файлы сбрасываются в каталог файлов вместе с работающими valgrind и busybox. Я не могу быть уверен, что memcheck-arm-linux - это именно то, что просят, если я не могу получить трассировку системных вызовов. IMHO Это было бы, не являющееся memcheck-arm-linux, что valgrind звонит здесь «memcheck» для платформы «arm-linux».

Дополнительная информация (аннотация на Дов, пожалуйста):

$ file busybox 
busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for 
GNU/Linux 3.2.0, stripped 
[...] 
$ file coregrind/valgrind 
coregrind/valgrind: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically 
linked, for GNU/Linux 3.2.0, not stripped 
[...] 
$ file memcheck/memcheck-arm-linux 
memcheck/memcheck-arm-linux: ELF 32-bit LSB executable, ARM, version 1 (SYSV), st 
atically linked, not stripped 

Видит никто почему valgrind кажется не будет принимать memcheck-arm-linux как действительный memcheck инструмент?

Answer 1

И наконец, strace разрешил эту проблему.

У вас еще нет следа, но strace очень четко сказал, что valgrind звонил memcheck-arm-linux с неправильным путем. Посмотрел какой-то путь от машины компилятора хоста, которая, очевидно, не существует на целевой машине.

Это намекал команда valgrind сборки должна быть изменена с

$ export CROSS_COMPILE=arm-unknown-linux-gnueabi- && export CC=${CROSS_COMPILE}gc 
c && export CPP=${CROSS_COMPILE}cpp && export CXX=${CROSS_COMPILE}g++ && export L 
D=${CROSS_COMPILE}ld && export AR=${CROSS_COMPILE}ar && ./configure --target=arm- 
unknown-linux-gnueabi --host=armv7a-none-linux-gnueabi --prefix=$HOME/valgrind-3. 
6.1/construct CFLAGS='-static -march=armv7-a' -verbose 2>&1 && make clean && make 
-j4 && make 

к:

$ export CROSS_COMPILE=arm-unknown-linux-gnueabi- && export CC=${CROSS_COMPILE}gc 
c && export CPP=${CROSS_COMPILE}cpp && export CXX=${CROSS_COMPILE}g++ && export L 
D=${CROSS_COMPILE}ld && export AR=${CROSS_COMPILE}ar && ./configure --target=arm- 
unknown-linux-gnueabi --host=armv7a-none-linux-gnueabi --prefix=/data/data/$APK_P 
ACKAGE_NAMESPACE/files CFLAGS='-static -march=armv7-a' -verbose 2>&1 && make clea 
n && make -j4 && make 

Вы можете увидеть --prefix теперь правильно установлен путь, который существует в целевом устройстве, и действительный. Запрограммированный. Грязные. Некрасиво. Но сейчас работает.