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

Question

Context разрабатывает приложение для 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.

Загружен на целевой телефон (версия Android 4.2.2 с ядром 3.4...), (context.getFilesDir() + File.separator + "valgrind").canExecute() возвращает ложь

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

Эмулятор вроде бы запускает ядро ​​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, но в любом случае выполняется как команда и аргументы от того, что он думает как args[2] до конца своего представления аргументов. valgrind загружается хорошо но не могу найти memcheck, Контекст здесь memcheck-arm-linux это статический двоичный файл с активами и дампами в каталог files вместе с работающими valgrind а также busybox, Я не могу быть уверен, memcheck-arm-linux это именно то, что просит, если я не могу получить трассировку системных вызовов. ИМХО это было бы гоча не быть memcheck-arm-linux какие valgrind здесь звонит "memcheck" для платформы "arm-linux".

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

$ 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 gave solution to this problem.

Don't still have the trace, but strace told very clearly that valgrind звонил memcheck-arm-linux with a wrong path. Was looking some path from the host compiler machine that obviously don't exist in the target machine.

That hinted the valgrind build command should be changed from

$ 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 is now correctly set to a path that exists in the target device, and is valid. Запрограммированный. Dirty. Некрасиво. But is working now.