I've previously had FPC (and Lazarus) running natively on Debian ARM, but I think it was "Etch"- things got a bit cloudy after that. The kernel being shipped with Lenny is 2.6.26-2 and I note

CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y

If I download the binary for 2.2.2 it won't compile a trivial app as it stands, but if I use OPT=-CfSOFT I can rebuild it or build a 2.4.0 that appears to work.

Is what I am doing reasonable, or should I- as an example- be using 2.4.0 to rebuild itself with -CaEABI before trying to go any further?

Mark Morgan Lloyd wrote

Is what I am doing reasonable, or should I- as an example- be using 2.4.0 to rebuild itself with -CaEABI before trying to go any further?

It's best to compile 2.4.0 with -dFPC_ARMEL (no need to use -CaEABI) and use the resulting compiler.

Jonas

Just a question: Why don't you download fpc 2.4.0 from debian squeeze and install it on your lenny box?

http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-rtl_2.4.0-2_armel.deb

Stefan

complete package list for armel:

http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-docs_2.4.0-2_all.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fpc-source_2.4.0-2_all.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fpc_2.4.0-2_all.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-ide_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-base_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-db_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-fcl_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-fv_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-gfx_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-gnome1_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-gtk2_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-gtk_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-math_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-misc_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-multimedia_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-net_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-units-rtl_2.4.0-2_armel.deb http://ftp.uk.debian.org/debian/pool/main/f/fpc/fp-utils_2.4.0-2_armel.deb

Thanks Jonas. It's worth noting that the hardware is an NLSU2 "Slug", so uname -a reports

Linux ... 2.6.26-2-ixp4xx #1 Mon Jun 21 20:07:59 UTC 2010 armv5tel GNU/Linux

I've got some meatier development boards but they came with CE and I've not found how to get Linux onto them yet.

If I use 2.2.2 to build an initial 2.4.0 like

make 'NOGDB=1' 'OPT=-CfSOFT' all
make 'OPT=-CfSOFT' install

I get something that can compile an app provided that I still give it -Cf. If I then try to use that to recompile itself with

make 'NOGDB=1' 'OPT=-dFPC_ARMEL' all

I get

/usr/local/bin/ppcarm -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE.
-FU/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux -dFPC_ARMEL -darm -dRELEASE -Us -Sg system.pp
thread.inc(332,10) Warning: Function result does not seem to be set thread.inc(344,11) Warning: Function result does not seem to be set thread.inc(354,11) Warning: Function result does not seem to be set thread.inc(359,11) Warning: Function result does not seem to be set thread.inc(364,11) Warning: Function result does not seem to be set thread.inc(393,10) Warning: Function result does not seem to be set thread.inc(412,11) Warning: Function result does not seem to be set thread.inc(436,11) Warning: Function result does not seem to be set thread.inc(442,11) Warning: Function result does not seem to be set thread.inc(483,10) Warning: Function result does not seem to be set /usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s: Assembler messages:
/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s:14465: Error: selected processor does not support `rfs r0' ..
/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s:56074: Error: selected processor does not support `stfd f0,[r5]' system.pp(373) Error: Error while assembling exitcode 1 system.pp(373) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted
make[7]: *** [system.ppu] Error 1
make[7]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/linux'

What should I be doing here- using both -Cf and -d?

Mark Morgan Lloyd wrote

What should I be doing here- using both -Cf and -d?

Yes, that should solve the problem. For the resulting EABI compiler, -Cfsoft will be the default.

Jonas

I've managed to get trunk working on my slug (also on debian lenny) quite a while ago, so I hope it's still possible. I was using trunk to build a cross compiler, though.

Henry

Henry Vermaak wrote

I've managed to get trunk working on my slug (also on debian lenny) quite a while ago, so I hope it's still possible. I was using trunk to build a cross compiler, though.

Thanks Henry. I've definitely had both FPC and Lazarus running natively on ARM in the past, but I suspect it was on Etch and that I ground to a halt when Debian started forcing the EABI transition. I do remember that I had a demo program for a Velleman K8055 interface board working on x86, SPARC and ARM... can't remember whether I ever tried it on PPC since I've only got a system fairly recently.

Is my recollection correct that somebody's working on the MIPS port?

Thanks Jonas, work continues and I'll report back.

Is there a way of getting FPC to report its build parameters? For example, if I say fpc -i to 2.4.0 I get

..
Supported ABI targets:
DEFAULT
..

but it doesn't actually say what the default is.

I'm sure Florian did some work on that. I have no experience with mips, but I saw that there are some Loongson laptops now. Exciting stuff.

Henry

I see discussion of it in this list last November, and reference to an fpc-mips project on Sourceforge.

To check whether or not you have an ARM EABI compiler, compile any file with -vei and verify that the output contains the line:

Target OS: Linux for ARMEL

(rather than "Linux for ARM")

Jonas

Thanks Jonas, noted.

Build still running- significant memory overcommit. I'll report back when done.

I can confirm that I can build FPC 2.4.0 to run under Debian "Lenny" on an ARM-based system (Cisco/Linksys NSLU2 "Slug") using

make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all

This appears to be OK to the extent that it can compile Lazarus 0.9.28.3, although my initial attempt ("make all") bombed but for some reason "make 'OPT=-vt' all" was OK.

If starting with a binary of 2.2.2 it's necessary first to generate 2.4.0 using 'OPT=-CfSOFT'. Obviously the amount of memory limits compilation and in particular linkage speed. I've not tried later versions yet.

When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with limited memory (32Mb RAM + 768Mb swap) and using it to compile a large project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go away if the make is restarted. I've not seen this running on other platforms, and I don't believe it is a problem in the Lazarus sources since the build will eventually complete giving me runnable code.

The output typically looks something like this, although I don't think it always fails at the same point:

$ make all
make -C lcl all
make[1]: Entering directory `/usr/local/share/lazarus-stable/lcl' /bin/rm -f units/arm-linux/alllclunits.ppu
/bin/mkdir -p units/arm-linux
/usr/local/bin/ppcarm -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset -Fu/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl -Fiinclude -FE. -FUunits/arm-linux -darm alllclunits.pp
Free Pascal Compiler version 2.4.0 [2010/08/21] for arm Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling alllclunits.pp
Compiling lclversion.pas
Assembling lclversion
..
Assembling postscriptprinter
Compiling postscriptcanvas.pas
Compiling postscriptunicode.pas
Fatal: Compilation aborted
An unhandled exception occurred at $00033B60 :
EInOutError : File not found
$00033B60
$000F6A30
$0011A744
$000FA588
$000F4F20
$00140A14
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$00024370
$00008304

make[1]: *** [alllclunits.ppu] Error 217
make[1]: Leaving directory `/usr/local/share/lazarus-stable/lcl' make: *** [lcl] Error 2

This is not immediately reproducible, so I can't simply rerun the compiler using gdb to get a backtrace. Is there an easy way to make sense of those numbers?

A couple of days ago I fixed an error in svn trunk for ARMEL that caused the stack to become temporarily unbalanced after performing syscalls with 5 or more parameters (the bug is still there for OABI, but I can't fix that because I don't have access to an OABI machine).

A side-effect of that bug was that if the caller passed the address of its own result as one of the parameters to the system call, it would afterwards return a random value as its result and checks for error results caused random failures like the one you posted (the reproducible case that allowed me to fix it was a similar error).

Jonas

I don't at the moment have any spare ARM systems that I could set up and expose for testing. I've got some development boards (effectively, ARM-based PCs) but they came with CE and I'm not paying the manufacturer $500 for Linux...

That sounds promising and I'll try it in a few days (once I've got the trial Lazarus compilations out of the way). What should I be doing- updating to trunk?

The overall exercise is extending the native testing I did of FPC on various platforms to Lazarus. Granted that not many people are likely to want to run it natively on an ARM target but I think it's still worth knowing whether it can be done.

I've requested an account on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm , anyone contributing to any free software project can do so), and I guess that at least one of their ARM machines will also support OABI binaries.

Maybe the easiest is to simply download http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/syscall.inc?revision=16073&pathrev=16073 and replace the rtl/linux/arm/syscall.inc file in the 2.4.0 source tree with that file. There are no FPC version-specific changes to that code.

The overall exercise is extending the native testing I did of FPC on various platforms to Lazarus. Granted that not many people are likely to want to run it natively on an ARM target but I think it's still worth knowing whether it can be done.

Sure!

Jonas

Jonas Maebe wrote

I've requested an account on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm, anyone contributing to any free software project can do so), and I guess that at least one of their ARM machines will also support OABI binaries.

If you don't get anywhere I might be able to help, although I'm not going to pretend that it would be convenient since I'd have to re-flash a Slug which would mean that I could no longer use it as an emergency fallback system. Things would be far easier if there were still such things as ARM-based workstations, i.e. booting from an external device (USB or whatever) rather than internal Flash.

The boards I've got are made by iEi, but you get either CE or Linux- not both. I'm hoping to be able to hack OpenFirmware onto a CompactFlash card which would give it much the same interface as Suns and PPC-based Macs.

Maybe the easiest is to simply download http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/syscall.inc?revision=16073&pathrev=16073 and replace the rtl/linux/arm/syscall.inc file in the 2.4.0 source tree with that file. There are no FPC version-specific changes to that code.

Noted, I'll report back presently.

My arm box is oabi.

That fix has a definite improvement on the reliability of the compiler. Before applying it I found that I couldn't get 2.4.0 to recompile itself, I had to revert to 2.2.2.

I have an ARM board with an OABI kernel running (because I wasn't yet eager enough to test how FPC behaves with an EABI uclibc ^^).

If you can tell me what I need to look out for I might be able to help you there.

Regards,
Sven

I now looked at the current actual code for OABI syscalls and it seems that the problem does not happen there. For OABI, the quick-exit trick is only used in a single stackframe-less function, and that's fine. Sorry for the false alarm.

Jonas

sorry for jumping in. I have a complex OABI application based on fpc 2.2.x and I um using a syscall with 5 parameters heavily. I had no problems so far, the applications runs stable. I am worried now, if I should adapt the actual OABI code to the old RTL?

Regards, Bernd.

Ok. Thanks for clarification.

Regards,
Sven