I got error when i tried to compile inline assembly with qadd command.
Error: cannot honor width suffix -- `qadd r7,r7,r1'
I know that qadd is supported in ARMv5TE
These ARM instructions are available in ARMv6 and above, and E
variants of ARMv5T.
C/asm code:
inline int __qadd(int a, int b) {
__asm__ (
"qadd %0, %1, %2" : "=r" (a) : "r" (a), "r" (b));
return a;
}
My cpu features is:
LOGI("__ARM_ARCH__='%d'", __ARM_ARCH__);
LOGI("__ARM_HAVE_5TE='%d'", __ARM_HAVE_5TE);
Output:
__ARM_ARCH__='5'
__ARM_HAVE_5TE='1'
I have next compiler flags:
LOCAL_CFLAGS += -std=c99 -ffast-math -march=armv5te
Besides i have tried replace add instead of qadd - nicely works but with qadd code not compiles.
What i'm doing wrong? Who can provide worked example of qadd command in assembly?
Solution here No qsort_r for Android (or how to disable force Thumb to use CLZ in Android ARM code)
In your Android.mk file, add ".arm" to the filenames and they will get
compiled as ARM mode instead of Thumb mode (e.g. sort.c.arm). I've had
mixed Thumb/ARM code in an Android native library and it worked fine.
Question is closed.
Related
I've two files:
lib.c
#include<stdio.h>
void hi() {
printf("Hi i'm a library function in lib.so\n");
}
and main.c
#include<stdio.h>
#include<dlfcn.h>
/* based on Jeff Scudder's code */
int main() {
void *SharedObjectFile;
void (*hi)();
// Load the shared libary;
SharedObjectFile = dlopen("./lib.so", RTLD_LAZY);
// Obtain the address of a function in the shared library.
ciao = dlsym(SharedObjectFile, "hi");
// Use the dynamically loaded function.
(*hi)();
dlclose(SharedObjectFile);
}
And I've tried to build an executables using the following commands:
export LD_LIBRARY_PATH=pwd
gcc -c -fpic lib.c
gcc -shared -lc -o lib.so lib.o
gcc main.c -ldl
And it works pretty well.
Then I've tried to export my program on Android (Nexus One, with ARM-v7-0a arch) using the following commands:
export LD_LIBRARY_PATH=pwd
arm-none-linux-gnueabi-gcc -c -fpic lib.c
arm-none-linux-gnueabi-gcc -shared -lc -o lib.so lib.o
arm-none-linux-gnueabi-gcc main.c -ldl -o main
adb push main /system/app
The result of executing ./main on the correct folder on my smartphone is just:
./main: not found
even if my file is right there!
Am I missing anything during the cross-compile process? Any help?
I'm using the cross-compiler from CodeSourcery and it works well for static programs without .so libraries.
Thanks
EDIT: as Igor states below, that was a linker issue. This command fixes it:
arm-none-linux-gnueabi-gcc -o test main.c -Wl,--dynamic-linker=/system/bin/linker -ldl
in my very case I need other libraries because in /system/lib/ there are no many .so files.
The "not found" message refers not to the shared object but to the dynamic linker. Linux uses /lib/ld-linux.so.2 (or /lib64/ld-linux-x86-64.so.2 for x64) while Android uses /bin/linker. You can check which dynamic loader your program uses with readelf -l, e.g.:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
You can specify a linker to use with ld's --dynamic-linker switch, but there are likely to be other differences. For example, Android uses a stripped-down libc implementation called bionic, and it may be missing functionality that your program relies on, or have different behavior.
You should use NDK or another Android-targeted toolchain when compiling programs for Android. Even though it's based on Linux kernel, the differences are large enough that Linux-targeted toolchains are not sufficient.
I've two files:
lib.c
#include<stdio.h>
void hi() {
printf("Hi i'm a library function in lib.so\n");
}
and main.c
#include<stdio.h>
#include<dlfcn.h>
/* based on Jeff Scudder's code */
int main() {
void *SharedObjectFile;
void (*hi)();
// Load the shared libary;
SharedObjectFile = dlopen("./lib.so", RTLD_LAZY);
// Obtain the address of a function in the shared library.
ciao = dlsym(SharedObjectFile, "hi");
// Use the dynamically loaded function.
(*hi)();
dlclose(SharedObjectFile);
}
And I've tried to build an executables using the following commands:
export LD_LIBRARY_PATH=pwd
gcc -c -fpic lib.c
gcc -shared -lc -o lib.so lib.o
gcc main.c -ldl
And it works pretty well.
Then I've tried to export my program on Android (Nexus One, with ARM-v7-0a arch) using the following commands:
export LD_LIBRARY_PATH=pwd
arm-none-linux-gnueabi-gcc -c -fpic lib.c
arm-none-linux-gnueabi-gcc -shared -lc -o lib.so lib.o
arm-none-linux-gnueabi-gcc main.c -ldl -o main
adb push main /system/app
The result of executing ./main on the correct folder on my smartphone is just:
./main: not found
even if my file is right there!
Am I missing anything during the cross-compile process? Any help?
I'm using the cross-compiler from CodeSourcery and it works well for static programs without .so libraries.
Thanks
EDIT: as Igor states below, that was a linker issue. This command fixes it:
arm-none-linux-gnueabi-gcc -o test main.c -Wl,--dynamic-linker=/system/bin/linker -ldl
in my very case I need other libraries because in /system/lib/ there are no many .so files.
The "not found" message refers not to the shared object but to the dynamic linker. Linux uses /lib/ld-linux.so.2 (or /lib64/ld-linux-x86-64.so.2 for x64) while Android uses /bin/linker. You can check which dynamic loader your program uses with readelf -l, e.g.:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00100 0x00100 R E 0x4
INTERP 0x000134 0x08048134 0x08048134 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
You can specify a linker to use with ld's --dynamic-linker switch, but there are likely to be other differences. For example, Android uses a stripped-down libc implementation called bionic, and it may be missing functionality that your program relies on, or have different behavior.
You should use NDK or another Android-targeted toolchain when compiling programs for Android. Even though it's based on Linux kernel, the differences are large enough that Linux-targeted toolchains are not sufficient.
Who can explain: how to enable intrinsics in c code?
I would like to use special dsp instructions in armv5TE
Consider qadd instruction, it nicely works when i use assembler approach, like this:
inline int function_qadd(int a, int b) {
__asm__ (
"qadd %0, %1, %2" : "=r" (a) : "r" (a), "r" (b));
return a;
}
But when i tried to use __qadd intrinsic instead of asm like this:
int add_result = __qadd(5,10);
LOGI("qadd='%d'", add_result);
i got error:
error: undefined reference to '__qadd'
What i am doing wrong, how to enable intrinsics in c code?
UPDATE:
I have ndk android-ndk-r8c (windows version), it have GCC 4.6 as default:
The GCC 4.6 compiler is still the default,
Besides i explicitly specify in android.mk
NDK_TOOLCHAIN_VERSION=4.6
My compiler flags is:
LOCAL_CFLAGS += -std=c99 -ffast-math -march=armv5te -mfpu=vfp -mfloat-abi=softfp
Besides i check the asm code generated by gcc throught -S compiler flag, it generate qadd instruction:
qadd r3, r3, r2
The intrinsic function __qadd is not available for the GCC compiler. The link to the documentation you've provided is for the (non-free) armcc compiler.
Using the assembler approach is the only practical way to use the qadd instruction if you're using GCC.
Android ndk told me "undefined reference to pthread_atfork" while I was trying to cross compile libpcsclite for Android
Actually I already knew there is no pthread_atfork function in Bionic library of Android (Android docs), but pthread_atfork must be called in pcsclite library. Is there any solution in this case?
It looks like pthread_atfork() was not added to bionic libc until after android-10/v2.3.6/Gingerbread. If you want to target older versions of Android, you either have to include pthread-atfork.c or the newer pthread_atfork.cpp in your project, or not use pthread_atfork() at all.
-DANDROID_PLATFORM=android-21
this value defaults to the lowest API level supported by the NDK in use
in my Context,use android-9 default.
if you execute shell below on your ${ANDROID-NDK} DIR,
find_path=$1
grep_str=$2
SOS=`find ${find_path} -name *.so`
for item in $SOS
do
echo ======= $item
objdump -Tt $item |grep ${grep_str}
done
sh echo.sh . pthread_atfork
the output:
======= ./platforms/android-9/arch-mips/usr/lib/libc.so
======= ./platforms/android-12/arch-x86/usr/lib/libc.so
00009420 g F .text 0000000a pthread_atfork
00009420 g DF .text 0000000a LIBC pthread_atfork
you will found this message:pthread_atfork is defined on libc.so with android-12 but not android-9.
so when you cross compile with cmake or other tools,you need add -DANDROID_PLATFORM=android-21 [just only gt android-9]
you can try this command with cmake
# on you project_root
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=/cross/github/jni/android-ndk-r14b/build/cmake/android.toolchain.cmake -DANDROID_TOOLCHAIN=clang -DANDROID_ABI=armeabi-v7a -DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang -DANDROID_PLATFORM=android-21 ..
Look at this: http://comments.gmane.org/gmane.comp.handhelds.android.ndk/15982
I believe function pthread_atfork is implemented in Bionic library (however, it's not documented).
I think all you have to do is to declare it to use it.
Usual caution: If you use undocumented methods, they may not work properly or may be deprecated in the future.
I have a really simple helloworld.cpp program
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
And I'm trying to compile it for android x86 with the cross-compiler from the toolchain:
/Users/me/android-ndk-r8/toolchains/x86-4.4.3/prebuilt/darwin-x86/bin/i686-android-linux-g++ helloworld.cpp -L "/Users/me/android-ndk-r8/sources/cxx-stl/stlport/libs/x86/" -lstlport_static
However, I get errors:
helloworld.cpp:2:20: error: iostream: No such file or directory
Any idea why?
Check the documentation.html file included with the NDK, under "Standalone Toolchain". It says that if you invoke the compiler in this way you won't be able to "use any C++ STL". However it is possible, as the documentation explains, if you first create a "customized" toolchain installation, using something like the following command:
$NDK/build/tools/make-standalone-toolchain.sh --platform=android-8 --install-dir=/tmp/my-android-toolchain --arch=x86
where $NDK is the path to your NDK directory. Note the --arch=x86 which means that the toolchain is prepared specifically for the x86 Android. This prepares what you need in one directory, including the STL headers and folders. You should then be able to use -lstdc++ to link against the STL (static version), i.e. something like:
/tmp/my-android-toolchain/bin/i686-android-linux-g++ helloworld.cpp -lstdc++
For a more complete explanation, please see the NDK documentation.
The NDK documentation is not entirely accurate, at least not currently. In fact, it states when using the prebuilt toolchain "You won't be able to use any C++ STL (either STLport or the GNU libstdc++) with it.", but this is out of date. I created a small hello world program using the include with the same error. It can be solved without creating your own toolchain though, which is nice if you don't want to have to add one more step to your configuration process and allows you to always use the latest SDK platform without creating a new toolchain every time.
The NDK ships with the source code for several versions of standard C++ libraries: GAbi++, STLport, and GNU STL. Each flavor comes with prebuilt shared and static libs as well. My example below will use stlport.
To use the stand-alone toolchain at its installed location, you can do something like this:
export CXX='$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ --sysroot="$NDK_ROOT/platforms/android-19/arch-arm"'
This, for example, would set your CXX compiler to compile ARM on the OS X system using SDK platform level 19. This much you probably already knew. Also, you would want to export your CC, CPP, LD, AR, and RANLIB if you use it. I also personally create an envar for READELF.
To add support for C++ libs, you could do something like follows:
$CXX helloworld.cpp -I$NDK_ROOT/sources/cxx-stl/stlport/stlport -L$NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi -lstlport_shared
Note that this will link the libstlport_shared.so which will now be required at runtime, so you may need to add a relative path to the command above to support that, depending on your APK structure. If you want to just test this simple case, you can just run this on the emulator as follows:
adb push a.out /data
adb push $NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi/libstlport_shared.so /data
adb shell
# su
# cd /data
# chmod 777 a.out
# ./a.out
To get rid of the headache of dealing with shared library paths, you can also statically link the C++ library in by changing "-lstlport_shared" to "-lstlport_static". There are some consequences of doing this, as explained in the NDK Dev Guide. The biggest issue is due to having the static library linked in multiple places, causing:
- memory allocated in one library, and freed in the other would leak or even corrupt the heap.
- exceptions raised in libfoo.so cannot be caught in libbar.so (and may simply crash the program).
- the buffering of std::cout not working properly
A useful tool is also included to see what dependencies your program has, the readelf tool.
To see what other shared libraries your program requires, you can run the following:
$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-readelf -a a.out | grep NEEDED
Other cool standard tools:
addr2line - convert a stack trace address to a line of code
nm - Displays the symbol table
objdump - displays info on an object
i call one of the functions from gnustl after it runs fine from prebuilt aosp arm-linux-androideabi-gcc --std=c++11 and after crashing error i cant get a backtrace from logs or reason, my hope is turning to crossbuilt qemu-linux-user to run host compiled i686 binary on the arm, difficulty is interacting with crosshost libs aapt from adt always crashes on any other than platform specific libs, unless kernel module packaged update is possible...