Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32 host. It fails at assembling system.s (produced from system.pp) with the following output:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error: bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error: bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error: bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error: bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error: garbage following instruction -- `ldrd r0,r1,[r0]' make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc download area:

arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?

Thank you!

Regards,
Nikolai

Hi all,

Ok, apparently the binutils-2.15.94-win32-arm-linux.zip (provided on the fpc website) is somewhat outdated to be really usable for arm target. Retrying with (self-built) binutils-2.28 apparently solves the previous problem but now I have another: ld yells something about VFP instructions:

T:/_tmp/fpcbuild-3.0.4/fpcsrc/compiler/ppcrossarm.exe -Tlinux -Parm -XParm-linux- -Xr -Ur -Xs -O2 -n -Fuarm -Fusystems -FuT:/_tmp/fpcbuild-3.0.4/fpcsrc/rtl/units/arm-linux -Fiarm -FE. -FUarm/units/arm-linux -dRELEASE -darm -dGDB -dBROWSERLOG -Sew -darm -dGDB -dBROWSERLOG -Sew pp.pas
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: warning: .\link.res contains output sections; did you forget -T?
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: arm\units\arm-linux\pp.o uses VFP instructions, whereas .\pp does not C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target specific data of file arm\units\arm-linux\pp.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target specific data of file
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\objpas.o uses VFP instructions, whereas .\pp does not
..... [lots of similar lines follow]

Any ideas?

Thank you!

Regards,
Nikolai

Hm, indeed, objdump confirms this VFP thing:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for some reason... Probably have to get rid of it somehow...

Thank you!

Regards,
Nikolai

It would be useful to know on which ARM/Linux platform you want to run your code (board/processor, and if it's an ancient board and/or kernel, whether it's ARMEL/EABI or not), and which command line options you are using to build FPC.

There is no single ARM/Linux platform, but many different incompatible ones (which is one of the reasons there are no provided FPC cross-compilers for this "platform".

Jonas

Nikolai Zhubr wrote

I suspect this is an inintended flag set by my arm-linux-as.exe for some reason... Probably have to get rid of it somehow...

so the real questions are:

1. is this flag being set erroneously?
2. are the .o files being built properly?
3. should ./pp (and others?) be rebuilt so that it does use/allow VFP instructions to be used?

... and -dFPC_ARMHF. It is more important than the others.

15.12.2018 17:38, Jonas Maebe:

Right, this is what I overlooked indeed (Well, because a pre-built native compiler for ARM did work successfully out of the box, producing perfectly usable arm binaries for me)

Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with VPFv4. The board is running either openwrt or opensuse. (And actually, the binaries produced by the pre-built native compiler have been tested in both environments already)

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ? If I use it, I get the following errors:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12587: Error: selected processor does not support `rfs r0' in ARM mode T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12590: Error: selected processor does not support `wfs r0' in ARM mode T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19745: Error: selected processor does not support `fcpyd d0,d1' in ARM mode T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19746: Error: selected processor does not support `fcpyd d1,d0' in ARM mode system.pp(379) Error: Error while assembling exitcode 1

Thank you!

Regards,
Nikolai

Nikolai Zhubr wrote

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?

is this a typo? should it be -CfVPF4_S16 with F and V swapped?

15.12.2018 18:24, Florian Klämpfl:

So, apparently most close to success for now was:
CROSSOPT="-CpARMV7A -CfvFPV2 -dFPC_ARMHF"

It successfully produced object files, but ld refsuses to link them. Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually accept that VFP is present, or rather I need to rebuild my binutils for a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp .\link.res)

Thank you!

Regards,
Nikolai

15.12.2018 19:09,

No. From ppcrossarm.exe -i:

Supported FPU instruction sets:
SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16

(And yes, such kind of abbrevations is always a bit frustrating to type and check, although it is obviously not fpc's fault)

Thank you!

Regards,
Nikolai

Hi again,

15.12.2018 19:52, Nikolai Zhubr:

I've got more results.

First, for completeness, here is my actual /proc/cpuinfo: Processor : ARMv7 Processor rev 4 (v7l)
processor : 0
BogoMIPS : 1434.46
processor : 1
BogoMIPS : 1439.63
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt

Currently, I'm trying with CROSSOPT="-CpARMV7A -CfvFPV3 -dFPC_ARMHF" (FPV4_S16 failed with some assembler complaints, posted earlier, so I then tried vFPV3 and it compiled, so I just stayed with it for now)

Still can not understand this ".o uses VFP instructions, whereas .\pp does not", but because I build binutils myself I've found and disabled the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags & EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build completed somehow. I can now produce arm-linux executables, but probably something is wrong anyway because this "VFP float format" is present in .o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
......
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?

Thank you!

Regards,
Nikolai

ok, it just jumped out at me because you had been talking about VFP but this was FPV... and apparently i goofed my above, too... i don't even know which one would be proper... it is just crazy that there are so many but that would be a standard, wouldn't it? :lol:

(And yes, such kind of abbrevations is always a bit frustrating to type and check, although it is obviously not fpc's fault)

i'm guessing that VFP is Virtual Floating Point which i would understand as being emulated kinda like we used to do when a machine didn't have a math co-processor in it...

Hi,

Is there any easy way to see how exactly ppcrossarm.exe invokes assembler (command-line arguments passed) during a cross-compiler build and also to inspect intermediate .s files?

Thing is, object files compiled from pascal (like system.o) still get this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6 -Cfsoft". However, object files compiled from assembler sources (like prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially crafted version of binutils as long as I target linux and build binutils from source. Standard binutils source tar compiles with almost zero effort on modern mingw, at least for linux target.

Thank you!

Regards,
Nikolai

Am Sa., 15. Dez. 2018, 23:55 hat Nikolai Zhubr
geschrieben:

You can try -sh which should generate a bat file inside the output directory that you can look at.

Regards,
Sven

Is there any easy way to see how exactly ppcrossarm.exe invokes assembler (command-line arguments passed) during a cross-compiler build and also to inspect intermediate .s files?

Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling intermediate .s files (when using -Cfsoft), not sure if it is correct and intentional, and no special flags passed to arm-linux-as while compiling assembler sources.
Hence the difference reported by objdump.

Now apparently, current binutils' ld wants that somehow fpu type is also specified for linking output if it was specified when assembling input and they probably need to match each other. I could not find such option, but e.g. gcc apparently has some way to automagically do it.

Thank you!

Regards,
Nikolai

Hi all,
16.12.2018 3:44, I wrote:
[...]

And after looking some more into current binutils, it seems machine code with this "VFP float format" and machine code without it are considered by ld not interoperable whatsoever. Therefore, when building for arm-elf, -mfpu=softvfp option should be passed either for _all_ generated object files or for _none_. Otherwise, linking normally can not succeed. And probably it is for a reason.

Apparently there is no way to explicitely specify something like -mfpu to ld, but because the setting can not be mixed anyway, the value is just inherited by the output elf executable from some (first ?) input object file ld encounters, afaics.

Looking into e.g. rtl/linux/Makefile[.fpc] there is e.g. this: $(AS) $(ASTARGET) -o $(UNITTARGETDIRPREFIX)prt0$(OEXT) $(ARCH)/prt0.as So inserting
ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated binaries are actually usable.

Thank you!

Regards,
Nikolai

Hi,

16.12.2018 13:51, I wrote:
[...]

So inserting ASTARGET+=-mfpu=softvfp allowed full cross-build to succeed. I have yet to see if the generated binaries are actually usable.

Ok, now the resulting elf executable has this (supposedly correct) flag: private flags = 600: [APCS-32] [VFP float format] [software FP]

And, helloworld still fails to run:
Illegal instruction

And, I still see tons of "ARM BLX instruction ..." warnings from ld of this kind:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM function 'SYSTEM_$$_POS$CHAR$SHORTSTRING$$LONGINT' C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM function 'fpc_shortstr_copy'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM function 'fpc_shortstr_to_shortstr'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM function 'SYSTEM_$$_DELETE$OPENSTRING$LONGINT$LONGINT'

Currently, my build command is:
make OS_TARGET=linux CPU_TARGET=arm NOGDB=1 CROSSCOMPILE=1 CROSSOPT="-CpARMV6 -Cfsoft" all

Any hints?

Thank you!

Regards,
Nikolai

Op 2018-12-15 om 22:27 schreef

No, VFP is hard float support. The "V" stands for Vector not Virtual

I followed the thread, but didn't find it: what binutils do you use?

Can you try those from

https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32/

? They work for me with the command line you mentioned. However, we have to support newer ones, I'll look into this.

Hi all,

(Sorry for flooding so much, but I've done some more testing!)

In order to isolate any possible wierd windows-specific issues, I've redone everything on x86_64-linux as a host, with the same 3.0.4 version starting compiler, same fpcbuild-3.0.4.zip as a source for cross-build, same arm-linux target and same binutils 2.31.1 built from stock source tarball, and same CROSSOPT="-CpARMV6 -Cfsoft".

Result seems exactly the same:

1. Adding the abovementioned ASTARGET+=-mfpu=softvfp to rtl/linux/Makefile[.fpc] is necessary, otherwise build will just fail.

2. Lots of "ARM BLX instruction ..." warnings from ld.

3. The resulting elf binary does not run on target device, generating "Illegal instruction"

So there definitely must be a problem somewhere.
Either I'm doing something really-really stupid, or maybe fpc 3.0.4 is incompatible with at least binutils >= 2.28 for arm target? I'm wondering what version of binutils was used to release fpc 3.0.4 for arm?

Thank you,

Regards,
Nikolai

Hi Florian,

16.12.2018 16:41, Florian Klämpfl:

I followed the thread, but didn't find it: what binutils do you use?

I've tried 3 version so far:

* binutils-2.15.94 (prebuilt) from fpc website is unusable because assembler refuses some instructions (I've mentioned it earlier)

* binutils-2.28-src for mingw, built by myself on mingw.

* binutils-2.31.1 regular source release, built by myself on both mingw and linux.

The latter 2 versions seem to show similar behaviour, resulting in the abovementioned results.

Thank you!

Regards,
Nikolai

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

16.12.2018 17:03, Florian Klämpfl:
[...]

https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32/ ? They work for me with the command line you mentioned. However, we have to support newer ones, I'll look into this.

With binutils from svn, the cross-build itself succeeded for me out of the box, although still producing "Arm BLX instruction ..." warnings.

But, the generated binary still does not work on the target device, generating "Illegal instruction".

I've noticed though that the binary has now a different set of flags, namely "[has entry point]" as compared to the ones produced by newer binutils, I guess that could be important:

objdump -p t
t: file format elf32-littlearm
private flags = 602: [APCS-32] [VFP float format] [software FP] [has entry point]

Apparently I'm now going to arrange some normal development environment on the target board directly to get further...

Thank you!

Regards,
Nikolai

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Which instructions does it show if you run the program in gdb and do "x/2i $pc-4" when it crashes?

Jonas

16.12.2018 18:13, Jonas Maebe:

Which instructions does it show if you run the program in gdb and do "x/2i $pc-4" when it crashes?

I made some additional steps in gdb in order to check if the program in question actually starts executing like it does:

GNU gdb (GDB; openSUSE Leap 42.3) 8.0
.....
Reading symbols from t-bad...(no debugging symbols found)...done. (gdb) info files
Symbols from "/root/personal/t-bad".
Local exec file:
`/root/personal/t-bad', file type elf32-littlearm. Entry point: 0x100ec
0x000100c0 - 0x000100e0 is .note.ABI-tag
0x000100e0 - 0x0003dff4 is .text
0x0003dff8 - 0x00042cf8 is .rodata
0x00053000 - 0x00053c5e is .data
0x00053c60 - 0x00055c18 is .bss
(gdb) break *0x100ec
Breakpoint 1 at 0x100ec
(gdb) run
Starting program: /root/personal/t-bad

Breakpoint 1, 0x000100ec in ?? ()
(gdb) x/2i $pc
=> 0x100ec: mov r11, #0
0x100f0: ldmfd sp!, {r1}
(gdb) stepi
0x000100f0 in ?? ()
(gdb) stepi
0x000100f4 in ?? ()
(gdb) x/2i $pc-4
0x100f0: ldmfd sp!, {r1}
=> 0x100f4: ldr r12, [pc, #92] ; 0x10158
(gdb) cont
Continuing.

Program received signal SIGILL, Illegal instruction. 0x0003155a in ?? ()
(gdb) x/2i $pc-4
0x31556:
stmdb sp!, {r0, r1, r2, r3, r4, r6, r7, r8, r9, r10, r11, r12, pc}
=> 0x3155a: ; <UNDEFINED> instruction: 0xfaff0060 (gdb)

Thank you!

Regards,
Nikolai

Hi,

I'm wondering what version of binutils was used to release fpc 3.0.4 for arm?

I've suddenly noticed that there is apparently no binary 3.0.4 release for arm! Well, at least not officially presented on fpc website. The download link goes to 3.0.2 version instead. Why is that? Is there any known problem with 3.0.4 on arm or rather it is supposed to be functionally identical to 3.0.2 ?

Thank you!

Regards,
Nikolai

thanks for the correction :)

Not exactly true. There is a release named "for raspberry" which is 3.0.4 and actually it seems usable for my board as well. Just installed it there, tested that same helloworld, and it worked! Wierd.

Thank you!

Regards,
Nikolai

FPC 3.0.4 generates BLX instructions while it must not do that. It is fixed in FPC trunk and the 3.2 branch. You can try to build the trunk version and test.
Or as a workaround you can set the armv5 cpu type via the -Cparmv5 switch. In such case BLX will not be used by FPC 3.0.2 too.

Yuriy.

Hi,

It seems I've finally cracked this puzzle, somewhat.

My self-built binutils were initially configured for "arm-linux" (That is, configure --target="arm-linux"). As soon as I changed this to "armv7-linux-gnueabi" (basically as a random guesswork) and rebuilt it all including the cross-fpc and my helloworld test on host x86_64-linux box again, I do not get much complaints from the build process anymore and the resulting executable appeared runnable on the arm device!

Now going to retry it on windows again...

Thank you!

Regards,
Nikolai

16.12.2018 20:20, Nikolai Zhubr:

So you tried to build the 3.0.4 sources? This is something I apparently missed.

Well, problem is a little bit that arm is really a moving target.

Hi,

Yes, "armv7-linux-gnueabi" did the trick for cross-compiling on windows as well. I just had to manually rename binary files of binutils so that thay match the naming pattern fpc build system expacts. I can provide my ready-to-use win32-to-arm binutils 2.31.1 zip if someone is interested.

Besides, I employed the "mkbinutils" script from contribs on the website, and I like it quite a lot, although it needed some little updating too. Its a pity this script is not mentioned anywhere in official recommendations.

I'd like to note that apart from this binutils target pitfall, cross-compiling appeared to be surprisingly easy even when both cpu and os of the target differ from the host ones. Really fantastic thing. But, the documentaion is horribly lacking/incomplete/outdated, and in the absence of fine official manual/howto, there are lots of unofficial "manuals" floating around, full of wrong/random/irrelevant instructions.

Anyway, this is a great success, thanks to all!

Regards,
Nikolai

16.12.2018 22:44, Florian Klämpfl:

Well, problem is a little bit that arm is really a moving target.

Yes, I know.
Besides, the exact difference between the "arm-linux" target and "armv7-linux-gnueabi" target is afaics just nowhere explicitely documented.(Though, binutils is opensource, one can read through and hopefully understand it... I tried a bit, but gave up soon.)

Thank you!

Regards,
Nikolai

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel