Hi,

Searching the mail from this list it seems there are a number of people that use fpc to compile for arm-embedded.
I would like to do also, but I never managed to get a clean compiler. With this I mean I can make a cross-compiler now, but when I use it to make a program I get an error at the linking stage. It is very frustrating that I seem to be the only one experiencing this, so I must be doing something wrong. This is what I do : I have a 'virgin' virtual linux machine, opensuse 12.3, with fpc 2.6.2 installed. I'm following the wiki :
http://wiki.freepascal.org/TARGET_Embedded

I have the sources of binutils-2.23.1. There I do : ./configure --target=arm-none-eabi --prefix=/usr
--program-prefix=arm-embedded- --disable-werror
make
sudo make install

arm-embedded-as -v

GNU assembler version 2.23.1 (arm-none-eabi) using BFD version (GNU Binutils) 2.23.1

I have fpc svn 25843 (downloaded today). There I do :

make clean
make buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv4 CROSSOPT="-CfSoft" PREFIX=/usr
sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv4 CROSSOPT="-CfSoft" PREFIX=/usr

As root I do :

cd /usr/bin
ln -s ../lib/fpc/2.7.1/ppcrossarm ppcrossarm

fpc -Parm -Tembedded -Wplpc2124 tled

Free Pascal Compiler version 2.7.1 [2013/10/23] for arm Copyright (c) 1993-2013 by Florian Klaempfl and others Target OS: Embedded
Compiling tled1.pp
Assembling program
Linking tled1
/usr/bin/arm-embedded-ld: error: no memory region specified for loadable section `.note.gnu.build-id'
tled1.pp(54,4) Error: Error while linking
tled1.pp(54,4) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /usr/bin/ppcrossarm returned an error exitcode (normal if you did not specify a source file to be compiled)

cat link.res

SEARCH_DIR("/usr/lib/fpc/2.7.1/units/arm-embedded/rtl/") SEARCH_DIR("/usr/lib/fpc/2.7.1/")
INPUT (
tled1.o
/usr/lib/fpc/2.7.1/units/arm-embedded/rtl/system.o /usr/lib/fpc/2.7.1/units/arm-embedded/rtl/lpc21x4.o )
ENTRY(_START)
MEMORY
{
flash : ORIGIN = 0x00000000, LENGTH = 0x00040000
ram : ORIGIN = 0x40000000, LENGTH = 0x00004000
}
_stack_top = 0x40004000;
SECTIONS
{
.text :
{

     _text_start = .;
     KEEP(*(.init, .init.*))
     *(.text, .text.*)
     *(.strings)
     *(.rodata, .rodata.*)
     *(.comment)
     _etext = .;
     } >flash
     .note.gnu.build-id : { *(.note.gnu.build-id) }
     .data :
     {
     _data = .;
     *(.data, .data.*)
     KEEP (*(.fpc .fpc.n_version .fpc.n_links))
     _edata = .;
     } >ram AT >flash
     .bss :
     {
     _bss_start = .;
     *(.bss, .bss.*)
     *(COMMON)
     } >ram

. = ALIGN(4);
_bss_end = . ;
}
_end = .;

When I do :

arm-embedded-ld link.res ls -l

total 312
-rwxr-xr-x 1 fpc users 357294 okt 23 09:33 a.out
-rw-r--r-- 1 fpc users 867 okt 23 09:31 link.res -rw-r--r-- 1 fpc users 3164 okt 23 09:31 tled1.o -rw-r--r-- 1 fpc users 1187 okt 23 08:55 tled1.pp

That seems to work. Dissassembling a.out seems to produce a valid assembly source. I also tried this with binutils-2.21.1 with the same problem.
Is there a way to see what parameters fpc generates to invoke the linker ?

I would be very gratefull when someone can pinpoint my error.

Thanks,

Koenraad Lelong

Koenraad Lelong wrote

Hi, Searching the mail from this list it seems there are a number of people that use fpc to compile for arm-embedded.

.
.

.
.

Are you aware of compiler option -s (or -sh, but that is the default for -s if I remember correctly)?

Tomas

Tomas Hajny wrote

On Wed, October 23, 2013 11:23, Koenraad Lelong wrote:

...

Hi Tomas,

fpc -Parm -Tembedded -Wplpc2124 -sh tled1.pp

Free Pascal Compiler version 2.7.1 [2013/10/23] for arm Copyright (c) 1993-2013 by Florian Klaempfl and others Target OS: Embedded
Compiling tled1.pp
tled1.pp(54,4) Fatal: Can't open executable tled1.elf Fatal: Compilation aborted
Error: /usr/bin/ppcrossarm returned an error exitcode (normal if you did not specify a source file to be compiled)

ls -l

total 16
-rw-r--r-- 1 fpc users 867 okt 23 11:55 link.res
-rw-r--r-- 1 fpc users 1187 okt 23 10:33 tled1.pp
-rw-r--r-- 1 fpc users 4710 okt 23 11:55 tled1.s

tled1.s seems the assembly-file of the source. link.res is the same as the one I get when I don't use -sh.

Thanks anyway.

Koenraad Lelong

Have a look at this file
http://freepascal.dk/files/fpcarm7.tgz
This is a 2.05 compiler, but I am still using it in produktion. This is an old package that uses LPC2138 as target. Now a days we use LPC2368 and LPC 2387 as target.
The compiler produce good code.
Regards
Carsten

Hi Carsten,

Unfortunately, my target will be STM32. I used the lpc to follow the wiki. Once I get that working I hope the STM32 will be working also. And I would like to use fpc 2.7.1 because I know that this version has enhanced interrupt-handling. I mean, it's easy to use interrupts, at least, I think, reading the sources of the cross-compiler. I once had a working STM32 cross-compiler but there you had to be very carefull when you defined interrupt-routines.

Thanks anyway.

Koenraad Lelong.

Hi Koenraad
I always write interrupt handling in assembler and then (if necessary) call an normal pascal procedure. This way I can controle how stack and memory issues are handled. I find i hard to believe that the compiler 2.71 can fulfil all your needs in that area. Regards
Carsten

Med venlig hilsen
Carsten Bager

BEAS A/S
Brørupvænget 10
DK-7650 Bøvlingbjerg
Tlf. : +45 9788 5222 Fax : +45 9788 5434
www.beas.dk

Can you try again after applying the attached patch?

Jonas

Thanks Jonas,

Now I can use -sh. The resulting ppas.sh :

#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; } DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; } echo Assembling program
/usr/bin/arm-embedded-as -mfpu=softvfp -o tled1.o tled1.s if [ $? != 0 ]; then DoExitAsm program; fi
rm tled1.s
echo Linking tled1
OFS=$IFS
IFS="
"
/usr/bin/arm-embedded-ld -g --build-id --gc-sections -L. -o tled1.elf -T link.res
if [ $? != 0 ]; then DoExitLink tled1; fi
IFS=$OFS
echo Linking tled1
OFS=$IFS
IFS="
"
/usr/bin/arm-embedded-objcopy -O ihex tled1.elf tled1.hex if [ $? != 0 ]; then DoExitLink tled1; fi
IFS=$OFS

Tinkering with it I found --build-id gives my problem. If that is removed, there are no errors.
But I also analyzed link.res :
SEARCH_DIR("/usr/lib/fpc/2.7.1/units/arm-embedded/rtl/") SEARCH_DIR("/usr/lib/fpc/2.7.1/")
INPUT (
tled1.o
/usr/lib/fpc/2.7.1/units/arm-embedded/rtl/system.o /usr/lib/fpc/2.7.1/units/arm-embedded/rtl/lpc21x4.o )
ENTRY(_START)
MEMORY
{
flash : ORIGIN = 0x00000000, LENGTH = 0x00040000
ram : ORIGIN = 0x40000000, LENGTH = 0x00004000
}
_stack_top = 0x40004000;
SECTIONS
{
.text :
{

     _text_start = .;
     KEEP(*(.init, .init.*))
     *(.text, .text.*)
     *(.strings)
     *(.rodata, .rodata.*)
     *(.comment)
     _etext = .;
     } >flash
     .note.gnu.build-id : { *(.note.gnu.build-id) }
     .data :
     {
     _data = .;
     *(.data, .data.*)
     KEEP (*(.fpc .fpc.n_version .fpc.n_links))
     _edata = .;
     } >ram AT >flash
     .bss :
     {
     _bss_start = .;
     *(.bss, .bss.*)
     *(COMMON)
     } >ram

. = ALIGN(4);
_bss_end = . ;
}
_end = .;

Deducing from the error-message :
/usr/bin/arm-embedded-ld: error: no memory region specified for loadable section `.note.gnu.build-id'

in ppas.sh I modified the line
.note.gnu.build-id : { *(.note.gnu.build-id) }
to
.note.gnu.build-id : { *(.note.gnu.build-id) } >flash

Then ppas.sh reports no errors.

I modified compiler/systems/t_embed.pas to have that line, and then the compilation of tled1 without -sh produces a tled1.elf. And the disassembled tled1.elf seems to be the program when comparing with a saved tled1.s.

So, is it safe to include that '>flash' to the linking script via the compiler ? Did I find a bug, or am I doing something wrong ?

Thanks for your support.

Koenraad

It can. And quite elegantly if I should say so :)

It now uses weak linking. Try to take a look at some of the Cortex-M* targets. The ARM RTL's haven't been converted yet, but I see no reason why they shouldn't be upgraded either. The new solution saves space and basically can't get any more efficient.

I think I remember that we had a discussion on build-id before, it did not work on linux but I thought that Florian has created a fix and I think I have verified that it works after that on my linux system.

Are you on Linux? And using trunk compiler? If you do not use trunk then
please try to use it, hopefully the fix is in there.

Michael

This article describes what build-id does:

https://fedoraproject.org/wiki/Releases/FeatureBuildId

your fix should get applied to trunk, the gnu-build section should end up somewhere, best place is flash, it will not get used anyway.

Michael

Michael,

I downloaded it this morning, svn trunk. And I'm working on linux. There was indeed a discussion (started jan 23, by me), but I never could compile an application, actually link the application, it was the same error. Today I looked into it again, and I hope I found a solution.

Regards,

Koenraad.

Well, the best would be if it ended up nowhere because it eats only flash memory.

Hi,

I modified t_embed.pas to not include that line in link.res : .note.gnu.build-id : { *(.note.gnu.build-id) } >flash

But I'm unable to locate where that '--build-id' is generated for the linker-commandline. If that is removed (only for arm-embedded ?), the build-id will not be generated, so no wasted memory.

Regards,

Koenraad.

Koenraad Lelong wrote

But I'm unable to locate where that '--build-id' is generated for the linker-commandline. If that is removed (only for arm-embedded ?), the build-id will not be generated, so no wasted memory.

Hi,

I found where the '--build-id' is defined : /etc/fpc.cfg Is this standard ? Or is this something the OpenSuse packager of fpc added ? I modified it to :
# ----------------------
# Use BuildId by default
# ----------------------
#IFNDEF EMBEDDED
-k--build-id
#ENDIF

Then is works. Could fpcmkcfg do this, as I understand that this is what generates a standard fpc.cfg when installing fpc ?

Koenraad

added ?

AFAIK we don't have this in the config by default (also -k is for passing options to the linker).

Regards,
Sven

The FPC standard installer does not write it, seems to come from Suse. At least I committed a change so it is put into flash if there is one.