Hi all,

For the Dutch among us: de dag die je wist dat zou komen...

Thanks to earlier help I got to build an ARM Linux cross compiler module in fpcup which even compiles fpcup itself (both using trunk and stable starting compiler):
opt="-fPIC -dFPC_ARMHF"
crossopt="-CpARMV6 -CaEABIHF -CfVFPV2"

fpc -g -gl -Tlinux -Parm simple.lpr

Question: should I have compiled with -fPIC?

Uploaded resulting executable
http://ubuntuone.com/0y3yXGcU8fEXR6OTMyvfGN

The program:
program simple;
begin
  writeln('hello');
end.

Relevant fpc.cfg snippet:
#IFDEF CPUARM
#IFDEF LINUX
-CpARMV6
-CaEABIHF
-CfVFPV2
-FDC:\development\cross\bin\arm-linux\
-XParm-linux-
-Xd
-FlC:\development\cross\lib\arm-linux\
-Xr/usr/lib
#ENDIF
#ENDIF

However, running the resulting binary on my virtual Raspbian fails with a segmentation fault. Running under gdb gives
(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault. 0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR () (gdb) bt
#0 0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR () #1 0x00008124 in _start ()

On the raspbian (which is built on hardfloat), file gives simple: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, not stripped

Compare with system-provided binary:
file /usr/bin/yes
/usr/bin/yes: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xf2df9a56df5c7b5490f7dba10f2163acb8971fce, stripped

Question: should I be worried about the GNU/Linux 2.0.0 above?

ldd simple
not a dynamic executable

I've run
readelf -a simple
uploaded to
http://ubuntuone.com/1cAX24nbcPkGo05fFWDbOr

readelf -a /usr/bin/yes
uploaded to
http://ubuntuone.com/6FD65xgakyE9eZOIme2z47

Question: what steps should I take now?

Thanks

I think this is an ARMV6 specific Problem, I also realized while debugging on embedded target that it does not work anymore, same code compiled for ARMV7 debugs (and runs) just fine...

Until now I did not find the time to search for the revision that broke armv6m.

Michael

Thanks Michael, guess I'll have to abandon my virtual Raspberry... or slowly bisect trunk revisions ;)

Maybe it is just using an unsupported instruction?

what does "x /10i $pc" return?

Pierre Muller

It looked more like the stack got messed up, for me it crashed after the second (if I remember correctly) procedure was called. I can dig into this on Sunday evening, after returning to my home.

Michael

(gdb) run
Starting program: /root/simple

Program received signal SIGSEGV, Segmentation fault. 0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR () (gdb) bt
#0 0x0002b6e4 in
SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR () #1 0x00008124 in _start ()
(gdb) x /10i $pc
=> 0x2b6e4
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+168>: str r0, [r2, r1]
0x2b6e8
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+172>: ldr r7, [r11, #-48] ; 0x30
0x2b6ec
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+176>: mov r0, r7
0x2b6f0
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+180>: ldmdb r11, {r4, r5, r6, r7, r8, r9, r11, sp, pc} 0x2b6f4
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+184>: andeq r7, r1, r4, lsr #23
0x2b6f8
<SYSTEM_$$_ARRAYSTRINGTOPPCHAR$array_of_ANSISTRING$LONGINT$$PPCHAR+188>: andeq r0, r0, r0, ror #4
0x2b6fc <SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR>: push {r4, lr}
0x2b700 <SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+4>: ldr r4, [pc, #24] ; 0x2b720
<SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+36> 0x2b704 <SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+8>: add r4, pc, r4
0x2b708 <SYSTEM_$$_STRINGTOPPCHAR$ANSISTRING$SMALLINT$$PPCHAR+12>: ldr r0, [r0]

Reinier Olislagers wrote

crossopt="-CpARMV6 -CaEABIHF -CfVFPV2"

The eabihf switch is not needed if the cross compiler is build with -dFPC_ARMHF.

Though it shouldn't change anything regarding the crash.

Thanks.

As I couldn't find any existing docs, I've started this page: http://wiki.lazarus.freepascal.org/ARM_compiler_options

Please feel free, as usual, to modify with corrections/additions.

Hmm, is this really needed? It clutters only information. I would completly remove the page and collect only the needed parameters for particular targets at their page because every arm target is different.

Please feel free, as usual, to modify with corrections/additions.

I see so need for the abi documention. Specifing the abi is normally not needed. It confuses only.

First off, thanks again for responding - I do really appreciate solid info from people who really know what's going on ;)

Hmm, is this really needed?

I actually would expect something like that in fpc docs, yes.

It clutters only information. I would completly remove the page and collect only the needed parameters for particular targets at their page because every arm target is different.

Well, that depends on your point of view - I think it nicely bundles information in one spot. Also, there may not be pages for all options (ARMv7 for example).
People compiling e.g. for Raspberry Pi may not care what all the options do but they would if they changed from e.g. the original softfloat raspberry debian to raspbian which has hardfloat. Having this kind of page IMO helps clarify nicely what the options are.

> Please feel free, as usual, to modify with corrections/additions. I see so need for the abi documention. Specifing the abi is normally not needed. It confuses only.

Well, I wouldn't know. I'm just collecting snippets from all over the wiki, forum posts, mailing lists and trying to make sense out of them (like the EABIHF versus -dFPC_ARMHF thing). Sort of trying to demistify a cargo cult....

Of course, I'll be happy to add a note saying that specifying the ABI normally is not needed - that'll save some other poor soul from wondering whether it's him, the phase of the moon or the wrong ABI parameter that caused the compiler to catch fire ;)

So when /is/ specifying the ABI needed? When supporting a microcontroller?

Just type fpc -i to see the possible options. If one does not understand those options, one does not need them :)

As said, arm targets are very different and every target has its optimal parameters. E.g. on my NAS running debian 6.0 I build for thumb with "CROSSOPT=-O4 -Cparmv5te -CIthumb"
and for normal arm with
"CROSSOPT=-O4 -Cparmv5te"
Depending on the distro, one needs different -Fl switches etc. Not to talk about different OSes.

People compiling e.g. for Raspberry Pi may not care what all the options do but they would if they changed from e.g. the original softfloat raspberry debian to raspbian which has hardfloat. Having this kind of page IMO helps clarify nicely what the options are.

Yes. But in my opinion then this info should go to the raspi page. I bet 99% of the raspi users don't know what instruction set the raspi needs. So explaining that -Cparmv6 turns on armv6 code generation does not help them :)

Yes, this unneeded -Caeabihf parameter floats around for years already :(

Simple: if you don't know when it's needed, you don't need it ;) Seriously: if you want to use an armel compiler to build e.g. for armhf. But then you probably want to have also some other defines and you really have to know what you are doing. Or if you have a special armel setup where you want to use hard float code and abi for speed reasons, e.g. when having softfloat raspberry debian installed. But these are special setups, officially not supported.

Florian Klämpfl wrote

Just type fpc -i to see the possible options. If one does not understand those options, one does not need them :)

I had a suspicion you were going to say that ;)

As said, arm targets are very different and every target has its optimal parameters.

Exactly. Having some additional info IMO helps to at least verify the choice somebody else made in his script/wiki page/build tool is correct ;)

Yep. -Fl is covered in the cross compiling article, of course also in the build faq.

Yes. But in my opinion then this info should go to the raspi page. I bet 99% of the raspi users don't know what instruction set the raspi needs. So explaining that -Cparmv6 turns on armv6 code generation does not help them :)

Ehm, this is exactly why I didn't put it on the raspi page ;)... but a link from there to the current page would be nice...

> So when /is/ specifying the ABI needed? When supporting a microcontroller? Seriously: if you want to use an armel compiler to build e.g. for armhf.

Ok.

Got it. Not interested in going that deep ;)

I had a look at armv6m yesterday evening, parts of my code run fine in gdb, the code crashes in the init of a procedure when trying to prepare the access to contents of a set.
The address of the set seems to get calculated totally wrong ending up in a memory access at the end of the chip's address range. Not sure if this is related to your problem, I will try to boil down the example to a bare minimum to see where the generated code differs between armv7m and armv6m.

Michael

Thanks a lot, Michael!

Just tried without -fPIC, and -CpARMV6Z=>compiles and runs nicely Rest of the options the same.

Tried again with -fPIC, -CpARMV6Z=>segmentation fault.

So I'll just leave -fPIC off then....

Could also cross-compile fpcup (which uses lclbase) and it seems to run.

@Michael, Jeppe etc: thanks a lot for the help, and hope the other problem gets solved.

Thanks a lot,
Reinier