Free Pascal > Unix

[SOLVED] Compiling for ARM

(1/3) > >>


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.

file hello:

--- Code: ---ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, not stripped

--- End code ---

readelf -l hello:

--- Code: ---Elf file type is EXEC (Executable file)
Entry point 0x80ec
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x3b8f0 0x3b8f0 R E 0x10000
  LOAD           0x03b8f0 0x0004b8f0 0x0004b8f0 0x07c60 0x09d80 RW  0x10000
  NOTE           0x0080c0 0x000080c0 0x000080c0 0x00020 0x00020 R   0x10
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.ABI-tag .text .rodata
   01     .data .bss
   02     .note.ABI-tag

--- End code ---

readelf -d hello:

--- Code: ---There is no dynamic section in this file.

--- End code ---

How can I make it produce working binaries or, for starters, figure out why exactly the binaries are rejected?

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.

Android strace -dfi ./hello:

--- Code: ---ptrace_setoptions = 0x1f
new tcb for pid 17292, active tcbs:1
 [wait(0x80137f) = 17292] WIFSTOPPED,sig=SIGSTOP,EVENT_STOP (128)
pid 17292 has TCB_STARTUP, initializing it
 [wait(0x80057f) = 17292] WIFSTOPPED,sig=SIGTRAP,EVENT_STOP (128)
 [wait(0x00127f) = 17292] WIFSTOPPED,sig=SIGCONT
 [wait(0x00857f) = 17292] WIFSTOPPED,sig=133
[0002f56c] execve("./hello", ["./hello"], [/* 20 vars */] [wait(0x000009) = 17292] WIFSIGNALED,sig=SIGKILL
 <unfinished ...>
[????????] +++ killed by SIGKILL +++
dropped tcb for pid 17292, 0 remain

--- End code ---

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.

Unfortunately that tool always uses FPC_ARMHF when selecting arm-linux or arm-android. I'm pretty sure by now that my boxes require ARMEL.
That -CfSoft example is "wrong" by the way. Building will fail because it is not supported with ARMHF.


[0] Message Index

[#] Next page

Go to full version