Recent

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

Starchild

  • New Member
  • *
  • Posts: 13
[SOLVED] Compiling for ARM
« on: November 14, 2017, 05:56:26 pm »
Hello,

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: [Select]
ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, not stripped

readelf -l hello:
Code: [Select]
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
   03     

readelf -d hello:
Code: [Select]
There is no dynamic section in this file.


How can I make it produce working binaries or, for starters, figure out why exactly the binaries are rejected?
« Last Edit: November 16, 2017, 08:17:04 pm by Starchild »

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Compiling for ARM
« Reply #1 on: November 14, 2017, 07:23:43 pm »
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.

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #2 on: November 14, 2017, 08:17:19 pm »
Android strace -dfi ./hello:
Code: [Select]
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
Killed

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.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Compiling for ARM
« Reply #3 on: November 14, 2017, 08:52:22 pm »
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.

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #4 on: November 14, 2017, 09:40:06 pm »
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.

https://puu.sh/ym3So/cb7ce77176.png
That -CfSoft example is "wrong" by the way. Building will fail because it is not supported with ARMHF.
« Last Edit: November 14, 2017, 09:47:35 pm by Starchild »

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Compiling for ARM
« Reply #5 on: November 14, 2017, 09:55:29 pm »
ARMHF for Linux and ARMEL for Android go together !

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #6 on: November 14, 2017, 10:15:17 pm »
ppcrossarm -CpARMv6 -darm -Tlinux -CfSoft hello2.pp
Code: [Select]
Free Pascal Compiler version 3.0.2-r35401 [2017/11/14] for arm
Copyright (c) 1993-2017 by Florian Klaempfl and others
Error: 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...
« Last Edit: November 14, 2017, 10:22:52 pm by Starchild »

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Compiling for ARM
« Reply #7 on: November 14, 2017, 10:28:39 pm »
Put
-dFPC_ARMEL in FPC options.
-CpARMV6 -CfSoft in cross-options.
Build crosscompiler.
Perhaps it will work.
« Last Edit: November 14, 2017, 10:30:12 pm by DonAlfredo »

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #8 on: November 14, 2017, 10:50:39 pm »
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.
« Last Edit: November 14, 2017, 10:52:41 pm by Starchild »

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Compiling for ARM
« Reply #9 on: November 15, 2017, 06:27:30 am »
FPC won't bite you anymore.
Its just the libs and the binary tools.

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.

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #10 on: November 16, 2017, 04:35:06 am »
Code: [Select]
F:\FPCUpDeluxeTrunk\cross\bin\arm-linux\arm-linux-gnueabihf-ld.exe: error: testapp uses VFP register arguments, eclib.a does not
F:\FPCUpDeluxeTrunk\cross\bin\arm-linux\arm-linux-gnueabihf-ld.exe: failed to merge target specific data of file eclib.a

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.

So yea, non-hf bins would be much appreciated.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: Compiling for ARM
« Reply #11 on: November 16, 2017, 08:12:49 am »
Here you go:
https://github.com/newpascal/fpcupdeluxe/releases/download/wincrossbins_v1.0/WinCrossBinsLinuxARMSoft.zip

The upcoming new release of fpcupdeluxe (1.6.0h) will try to automate the choice of correct binutils based on the settings by the user.

Starchild

  • New Member
  • *
  • Posts: 13
Re: Compiling for ARM
« Reply #12 on: November 16, 2017, 08:16:34 pm »
With those and the correct target libraries everything is working as it should now.

Thanks a lot, DonAlfredo, your help was invaluable.

 

TinyPortal © 2005-2018