Author
Topic: [SOLVED] Compiling for ARM (Read 1903 times)

I'm trying to get FPC to build for ARM. My target system has a ARM1176EJ processor and is running Linux 2.6.34. I cross-compiled FPC 3.1.1 (r37585) mostly following Setup Cross Compile For ARM. The host system is Manjaro 17 x86_64, same FPC version.

Now the problem is:When I compile a simple Hello World program and run it on the target, all I get in the console is an immediate "Killed". The process always exits with code 137 (received signal 9, kill). I tried it on both, the actual target and an Android smartphone. Neither system gives any hint as to why it won't run the binary, there is nothing in the kernel logs (nor in logcat for Android). I even tried remote debugging using IDA's armlinux debug server, but apparently the process doesn't even load to the stage where it'd become debuggable.

It doesn't make any difference whether I use -CpARMv5T or -CpARMv6. The cross-compiler was built with -dFPC_ARMEL, and in the arm-linux-as script I set -meabi=gnu (I figured that's what to use because the C compiler is called arm-cx2450x-linux-gnueabi-gcc). I didn't try the -Cf flag because I don't know which option would be correct (I suppose "soft", but wouldn't that be the default?).

I don't know much about the ELF format, but I couldn't see anything wrong looking at the file in IDA.

Try running it under strace, the last few lines might tell something. You can also try running it under GDB which hopefully will tell you what happened. -Cf shouldn't matter for a hello world, but -Cp might be. -dFPC_ARMEL should be correct for Android, might not be for regular Linux.

The other system doesn't have strace and I couldn't find a working build for it, but I assume the output would be the same. I'm under the impression that the process doesn't even get to execute a single line of its machine code. If it were an instruction set issue or segfault or anything, it should say that instead of an instant SIGKILL.

The WiKi-instruction you have followed can be a bit outdated.You could try to use fpcupdeluxe, and see if it makes any difference.Step1: let fpcupdeluxe install stable or trunk on your system.Step2: let fpcupdeluxe install cross-compilers for arm-[linux/android].Maybe this will help you.

Free Pascal Compiler version 3.0.2-r35401 [2017/11/14] for armCopyright (c) 1993-2017 by Florian Klaempfl and othersError: You must use a FPU type of VFPV2, VFPV3 or VFPV3_D16 when using the EABIHF ABI target(Used stable instead of trunk for testing here)

I was like "okay let's try vfpv2 anyway even though it won't work" --> I don't get "Killed" anymore, but "Illegal instruction". The compiler produced an ARMv7a binary which will not run on the ARM11 processor (I guess because vfpv2 is meaningless in ARMv6). On the Android phone (which has a much more modern processor) it runs though!So to target an ARMEL Linux I actually need to use the android compiler? That's quite confusing, but I'll give it a try...

Ah excellent! That did it. The soft floats are also working fine according to some small tests I did.

One final question: With these options it's still using the arm-linux-gnueabihf-* binutils. Will the fact that those are gnueabihf and not gnueabi possibly bite me in the ass sometime? Things I might wanna do later on include statically linking C objects, dynamically linking against C libraries, writing libraries that C binaries will link against.

If the libs bite you: copy over the libs of your target system into the correct cross/lib-directory.If the bins bite you: just let me know; I will try to build the correct ones and add them for fpcupdeluxe.

As soon as I include anything that uses dynamic libraries (just the dynlibs unit alone is enough already) I get that error. eclib.a is a static library compiled by GCC without hard float support. If I don't include the static library, the binary runs even though the ELF has the EF_ARM_VFP_FLOAT flag, but I guess that's just because FPC didn't emit any instruction that uses a float register. A hacky workaround would be to compile the eclib with hard float as well, but I'm quite afraid I'll be haunted by "Illegal instruction" faults if GCC gets some optimization ideas etc.