I'm still a newbie to assembly language and cross-compiling etc. I've already googled the problem I'm having and seen a few similar posts but none of them solved my problem unfortunately.
We're learning ARM32 Syntax at the university and playing around with assembly code on AARCH64 machines on a uni server. So we need to cross-compile the .s files to be able to run them.
We use the command arm-linuxgnueabihf-gcc to cross-compile.
Now the system (the loader I guess) is configured properly to execute these 32-bit cross executables. When I tried to debug a 32b exec however GDB crashes with error: selected architecture armv7 is not compatible with reported target architecture aarch64
There are screenshots below that illustrate the problem. Thanks for any help!
System infos:
System info
No error with native compiler:
No error with native compiler
Error with cross-compilation:
Error with cross-compilation
I am building zephyr on Raspberry Pi 3b to use nRF52840 dongle. Follow the tutorial Getting started with Zephyr
Everything includes:
download
install
cmake -DBOARD=nrf52840_pca10059 ..
was ok until I "make" in build/, issue occurred:
/home/pi/zephyr/ext/hal/cmsis/Include/core_cm4.h:105:8: error: #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
#error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
Has anyone:
used Zephyr with RasPi 3b?
used RasPi 3b with nRF52840 dongle?
can solve this problem?
The GCC that you were using gcc-arm-linux-gnueabihf is the incorrect gcc to use. You should be using arm-none-eabi-gcc which the PI uses specifically.
Along with that, you can disable the generation of FPU instructions and SIMD (Single Instruction Multiple Data) by using -mcpu=name+attribs where it might be -mcpu=cortex-a53+nofp+nosimd.
See http://gcc.gnu.org for documentation on -mcpu.
I'm attempting to debug a program in Code Composer Studio compiling with the GNU toolchain rather than the default TI, it's my understanding that CCS by default only places CCS breakpoints which are not recognized by the GDB when working in a CCS project.
My code is inside a CCS project hence my breakpoints are being ignored. I read somewhere that when working inside a C/C++ project the breakpoints placed will be GDB breakpoints but when working inside a C/C++ project it doesn't seem to actually run the code on the microcontroller itself.
I need to be able to debug my code running on the microcontroller itself while also using the GNU compiler toolchain but I can't seem to find a way to do this.
Please check target configuration. What kind of hardware is it ? Does the hardware support hardware breakpoints ? Is the program flashed correctly ? Some hardware support only a limited number of hardware breakpoints. Gnu toolchain should also include "-g" or "--symdebug:dwarf".
I would like to link a cross-compiled library (library.a) compiled with soft floating point support (arm-none-eabi) on a system with support for hard floats (Raspberry Pi - armv7l-unknown-linux-gnueabihf) and run it with a test application.
Unfortunately I am getting a linker error:
/usr/bin/ld: error: application uses VFP register arguments library.a(library.c.obj) does not.
Any idea on how I could tell to gcc to build the executable with soft floats and the link to the rest of the system with VFP register arguments?
An alternative approach I have tried is to use the gcc-arm-none-eabi package available on raspian. I tried compiling my dependencies with
export CC="arm-none-eabi-gcc -I/usr/arm-linux-gnueabi/include/"
export LD="arm-none-eabi-ld -L/usr/arm-linux-gnueabi/lib/"
Unfortunately this compiler does not have Linux support integrated and I'm missing various references.
My current bet is now to build a cross-compiler toolchain with soft float for the raspian and the use this build to link and run my application.
I'm interested in compiling the sourceforge project https://svn.code.sf.net/p/archopen/code/ArchOpen/trunk/, and more especifically the app AOnes, which is a NES emulator for Archos Gmini 400 (Inactive old project)
Analyzing the source code, I saw that the Gmini400 is an arm7tdmi device, no MMU and the toolchain used to compile was a buildroot one named arm-linux-nofpu.
I supposed (according to the buildroot-2009-02 menuconfig) that no-fpu means soft floating point, so i tried to build such a toolchain.
I build a toolchain with buildroot-2013-02 (both year 2009 and 2010 don't work for me) with the following options:
arm7tdmi
no MMU
Software Floating Point
Enable elf2flt support (i saw there were such a reference in the
Makefile of ArchOpen)
I let the other options as they were and made the build.
I made a checkout of ArchOpen, launch the configuration script to choose Gmini4XX as the target (and not Gmini 402 chich is quite different), selected to defaut.rules and edit the resulting Makefile.conf to adapt the tools paths and names (as my generated toolchain name is different)
First error:
[thread.o]
{standard input}: Assembler messages:
{standard input}:1236: Error: Rn must not overlap other operand -- swpb r0,r3,[r0]
Well, this code is supposed to be working, but i opened thread.h and corrected the source to pass through (adding a "&")
Second error:
undefined reference to __aeabi_idivmod and undefined reference to __aeabi_ldivmod
As google says, it seems to be a -lgcc missing problem.
I edited the wav folder makefile to add -lgcc and specified -L/lib_folder_of_my_toolchain_containing_libgcc.a
Third error:
in gcc/config/arm/lib1funcs.asm : multiple definition of __divsi3
in gcc/config/arm/lib1funcs.asm : undefined reference to raise
in libgcc.a (some .o inside) : undefined reference to __aeabi_unwind_cpp_pr0
I've no idea to solve this...
Does anyone have an idea? Does anyone can help me to get a working arm7 toolchain compatible with this archopen code?
Thanks!
Well, in this particular case, back to 2005 was a good solution...
With a ubuntu 5.04, buildroot has been built with the defaut generic ARM (little endian) configuration, except for the following options:
GCC 3.3.5
No use the daily uClibc snapshot
The processor has no MMU
No support large file
Use softfloat by default
No install busybox (as I only wanted the toolchain)
No create an Ext2 filesystem (same reason than above)
The build fail just after having compiled the last GCC phase. At this point, add the buildroot/build_arm_nofpu/staging_dir/bin in the PATH env. variable, download the libfloat source (libfloat-990616.orig.tar.bz2) tarball, edit the Makefile changing gcc, ld and as repectively by arm-linux-uclibc-gcc, arm-linux-uclibc-ld and arm-linux-uclibc-as and build libfloat (make clean & make). Copy libfloat.a into buildroot/build_arm_nofpu/staging_dir/lib and run the buildroot make again (without cleaning). The build should end successfully. With this toolchain, mediOS will compile without any warning.