works for me, using svn 7929, compiled for arm little endian with soft float.

henry

Hi Everyone;

Please, can someone test this program and write to the list if it works in arm-linux.

program datetostr_test;
uses sysutils;
begin
writeln(datetostr(now));
end.

I always receive

An unhandled exception occurred at $BEED89C8 :
EAccessViolation : Access violation
$BEED89C8

if for someone this program work, please write me with your Fpc for arm version.

thank you in advanced

best regards

Jose Pascual

josepascual wrote

I have downloaded svn version 7943 how can I donwload svn 7929?

svn update -r 7929

Thank you henry,

I have downloaded svn version 7943 how can I donwload svn 7929?

How are you build fpc for arm? make clean crossall CPU_TARGET=arm OS_TARGET=linux ....?
Which version of binutils do you have? (eabi?)
Is SOFTFLOAT in freepascal the equivalent to EABI in c?

thank you!
Jose Pascual

En/na josepascual ha escrit:

same here (only at a different address), though I have many funky errors under arm that nobody else has.
Using self-built native fpc-2.1.4

uname -a
Linux lspro 2.6.12.6-arm1 #77 Tue Dec 5 22:23:46 CST 2006 armv5tejl GNU/Linux
cat /proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 266.24
Features : swp half thumb fastmult edsp java CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 1
I line length : 32
I sets : 1024
D size : 32768
D assoc : 1
D line length : 32
D sets : 1024

Hardware : MV-88fxx81
Revision : 0000
Serial : 0000000000000000

Bye

soft float just means that the compiler needs to emulate the floating point unit if it doesn't exist in your hardware (like some arm processors). if you have an fpu, then you don't have to worry about soft float. the following assumes that you need soft float in you compiler.

passing OPT='-CfSOFT' doesn't work anymore, so you have to edit your Makefile.fpc and look for the line BUILDOPTS=... add your extra options there (i usually add OPT='-gl -CfSOFT'). then you will have to go fpcmake -rTall.

then you can do make clean crossall with the usual suspects passed to it, like CPU_TARGET, OS_TARGET, BINUTILSPREFIX, etc).

use the binutils that came with your device, or use something that someone else used successfully.

make crossinstall still fails towards the end, but that's o.k. your cross compiler will be there and ready to use.

sorry if i'm making any mistakes here, it's off the top of my head. i haven't got my build machine here...

thank you! Jose Pascual

henry

En/na Henry Vermaak ha escrit:

If this program compiles and works fine:
program floattest;
uses sysutils;
var a,b:double;
begin
a:=0.5;
b:=0.3;
writeln(format('%5.3f',[a*b]));
end.

can I assume that either my compiler has been built with the right options or I have a working fpu?
I'm asking because jose original test program fails here, while the above program correctly prints out 0.150

Bye

yes.

I'm asking because jose original test program fails here, while the above program correctly prints out 0.150

does the above work if you set a or be to a negative number? my softfloat crashes with writeln(negative number).

maybe you should try fpc 2.3.1, since that's the one i'm using and my datetostr is working...

Bye -- Luca

cheers
henry

Are you sure? If I remember right, using softfloat in conjunction with fpc means, that the compiler never emits floating point operations. All the floating point is going through the softfpu unit. This means, *if* you have a fpu, you waste speed.

Regards, Bernd.

En/na Henry Vermaak ha escrit:

Yes

maybe you should try fpc 2.3.1, since that's the one i'm using and my datetostr is working...

Maybe I'll try (I supposed it can be compiled natively), but then, what's the purpose of a "stable" and "beta" fpc release if we have to leapfrog to the next devel version? (or I'm just confused by the release numbering and 2.3.1 is not the next devel version?).

Bye

that's right. i've got two arm devices without fpus, though...

Regards, Bernd.

henry

The ARM926EJ-S core does not have a FPU but an interface for coprocessors. So if there is floating point hardware built in depends on the chip manufacturer.

Not having FPU hardware is currently the most possible case for ARM7 and ARM9, the only chip I know of having a VFP9 FPU is the LPC3180 from Phillips. This may change, at least Fujitsu has some designs in the pipeline for 3rd or 4th quarter of this year IIRC.

Marc

the program works for me.

FPC 2.1.4 compiler built without softfloat option, running on an (little endian) ARM processor without fpu on Linux, kernel version 2.6.21.1 (OABI).

ppcrossarm -gl datetostr_test.pas

Regards, Bernd.

En/na Bernd Mueller ha escrit:

could you check bug 9191?

http://www.freepascal.org/mantis/view.php?id=9191

Bye.

En/na ha escrit:

I do simply an "fpc pippo.pas" (or "fpc pippo2.pas"), I'm running it directly on the arm, I'm not cross-compiling (that's why I asked you, I wanted to see if cross-compiling makes a difference). My fpc.cfg is what the installer for 2.1.3 generated, manually amended for 2.1.4 (consider that fpc is installed under /home/luca/fpc-2.1.4). It's attached.

Bye

The -ldl refers to libdl.so, not to dl.o. You have to copy it from your ARM system to your Windows machine, and add the directory with all your ARM libraries to the linker's search path, like Luca did: -Fl/usr/lib/gcc/arm-linux-gnu/4.1.2

(or wherever the libraries are located on your system)

Jonas

I have a ARM920T (without fpu, kernel OABI)

I have (always in linux) a fpcrossarm compiler version 2.1.4 and one 2.3.1 (I don't know release).

I can compile with 2.1.4 with and without softfloat but 2.3.1 only without softfloat.

I have compiled floattest with :

a) ppcrossarm 2.1.4 without CfSOFT --> result 0.150 b) ppcrossarm 2.1.4 with CfSOFT --> result 0.000
c) ppcrossarm 2.3.1 without CfSOFT --> result 0.150

but I can run datetostr_test without error.

Hi henry et all,

I have a little confused, Could you or someone help me with some question?

I have a ARM920T (without fpu, kernel OABI) .
Which version of gcc are you using 3.4.1? 4.1.2?
Which libc version? (2.3.2 2.3.6)
Is your gcc for EABI?
Have you used same crosstools to generate fpc 2.3.1 libraries and to compiling your final freepascal programs?
Can I Use a FPC for ARM (cross or not) with softfloat option for arm kernel EABI and not EABI (OABI)?
What Freepascal only use from ARM binutils? (as, ld, ar, ranlib, ... Whats ()? (gcc is not necesary, is it?)

4.1.1 (this is the first gcc that supports eabi).

Which libc version? (2.3.2 2.3.6)

2.3.90.

Is your gcc for EABI?

yes.

Have you used same crosstools to generate fpc 2.3.1 libraries and to compiling your final freepascal programs?

yes.

Can I Use a FPC for ARM (cross or not) with softfloat option for arm kernel EABI and not EABI (OABI)?

i dunno. only kernel 2.6.16 onwards support eabi, afaik, and the two aren't compatible, although you might be able to make it work if you know which settings to change in i_linux.pas, but i think it's not that simple.

i know that ld have complained about linking my fpc programs with libraries, but i suspect that's an interworking-related thing. luckily ld does have some options to control this.

any fpc developer care to comment?

What Freepascal only use from ARM binutils? (as, ld, ar, ranlib, ... Whats ()? (gcc is not necesary, is it?)

only as and ld, i think?

i urge you to read this:

http://wiki.debian.org/ArmEabiPort
http://www.codesourcery.com/gnu_toolchains/arm/faq.html

i haven't completely read it (hence i can't answer your questions that well, sorry).

henry

Hi everyone

I have compile datetostr_test with -g and I have run program with GDB

this is the error output in gdb

Starting program: /tmp/datestrto_test

Program received signal SIGSEGV, Segmentation fault. 0x0000bcc8 in fpc_ansistr_decr_ref ()

It seems the problem is not exactly in datetimetostr but the string system.

Any opinion or suggestion?

Jonas Maebe wrote

The -ldl refers to libdl.so, not to dl.o. You have to copy it from your ARM system to your Windows machine, and add the directory with all your ARM libraries to the linker's search path, like Luca did: -Fl/usr/lib/gcc/arm-linux-gnu/4.1.2

thank you Jonas, that was helpful. I finally was able to compile the file, but I think there is still a problem with the libraries. The program does not run as expected.

Regards, Bernd.

i've reported this a while ago. i added a back trace the other day:

http://www.freepascal.org/mantis/view.php?id=8737

regards Jose Pascual

henry

negative number problem is not in float operation but in format or strings subsystem.

try this new example:

program floattest;
uses sysutils;
var a,b,c,d,e:double;
begin
a:=0.5;
b:=0.3;
writeln(format('%5.3f',[a*b]));
a:=-0.5;
c:=a*b;
d:=a*c;
writeln(format('%5.3f',[d]));
if (c < 0) then
begin
//  e := abs(c); seems not to work! please remove // and try it
  e := -1*c; // remove or comment if you use abs in above line
  writeln('-'+format('%5.3f',[e]));
end;
end.

perhaps, I think now, part of problem can be in something relative abs or used by abs.

comment your results,

regards

Jose Pascual

I finally got your program crosscompiled on my windows machine. But if I start it on the linux target, I get the output "not found". I think, I made something wrong, when I tried to resolve the library .so symlinks. Another problem was, that my ARM Linux uses uClibc and not libc, so the linker complaint about some missing references in cprt0. I made changes in cprt0.as and recompiled the rtl.

I need more time (and experience) to track this problem down.

Regards, Bernd.

En/na Bernd Mueller ha escrit:

thank you Jonas, that was helpful. I finally was able to compile the file, but I think there is still a problem with the libraries. The program does not run as expected.

not expected as in the bug report or something completely different?

Bye

completely different. The program seems to start and terminates then with the output "not found". As if the shell could not find the program. I need to install gdb on the target, to get more information.

Regards, Bernd.

En/na Henry Vermaak ha escrit:

I'm wondering if my strange problems are due to a badly built compiler and/or rtl.
I know for sure that my kernel (that I cannot upgrade at the moment) supports OABI and has EABI badly patched in (i.e, it doesn't work 100%), everything else should be OABI (debian arm, not armel). To build 2.1.4 I used a binary snapshot of 2.1.3
(ftp://ftp.freepascal.org/pub/fpc/beta/2.1.2/arm-linux/) and did not specify any special option while building, so, what convention is my compiler/rtl using? Is it possible that it's generating EABI and hitting sometimes the special cases that don't work in my kernel? In that case, how should I rebuild it in order to generate OABI code?

Bye

you did not mention a third possibility: the compiler itself has some serious issues. See the various bug reports in the mantis bug tracker.

I guess that fpc does not care about OABI/EABI. The compiler ether generates fpu opcodes or not (when floating point is used). This depends on the -CfSOFT option while building the compiler/rtl.

Perhaps one of the developer can confirm or deny this. Thanks.

Regards, Bernd.

En/na Bernd Mueller ha escrit:

I guess that fpc does not care about OABI/EABI. The compiler ether generates fpu opcodes or not (when floating point is used). This depends on the -CfSOFT option while building the compiler/rtl.

Yes, but I think that fpc generates its own syscalls (not going through libc), and if I'm not mistaken, these are different in OABI vs EABI

Bye

FPC can do both, but syscalls are default because these binaries are more portable across distributions (and versions) than glibc and thus easier to deploy. (and recently, libc has been broken after the introduction of the new syscalls. There is a release blocking bugentry for that in Mantis, so I expect that to be solved soon).

En/na Marco van de Voort ha escrit:

But are they OABI or EABI under arm (or is there no difference?).

Bye

I don't think anyone has ever tried to use the libc-based rtl with linux/arm.

Jonas

En/na Jonas Maebe ha escrit:

And without using libc, what kind of syscalls do fpc generate OABI or EABI? (or, again, is there no difference between the two?)

Bye

I have no idea. You could try comparing /usr/include/asm/unistd.h on an OABI and EABI system for a start, although that will tell you nothing about which parameters have to be passed and in what way (only the syscall numbers themselves).

Jonas

En/na Jonas Maebe ha escrit:

supposedly (I'm not really into system level programming) oabi syscalls start at 0x900000, while eabi ones start at 0, so, by looking at rtl/linux/arm/sysnr.inc it seems that fpc should be generating oabi calls, so my problems with arm are coming from somewhere else.

Bye

Can't you try to write a simple program using the functions in question and compile with "fpc -al"?

That way the assembler source should show some useful information about the system calls in use.

HTH,
Marc

En/na Marc Santhoff ha escrit:

Can't you try to write a simple program using the functions in question and compile with "fpc -al"?

the syscalls are in the rtl, so they won't show up in my program (not that I understand asm assambler, but according to
http://sourceware.org/ml/libc-ports/2005-11/msg00028.html the syscall is "swi 0x0900....." and there's no "swi" instruction in my code).

Bye