[fpc-devel] targetandroid - can't build for armv7, hangs on pooledmm.pp
I've tested the new targetandroid branch, and by using fpc 2.6.0 and making a new fpcmake (taken from the targetandroid branch), I'm able to compile for armv5: make crossinstall OS_TARGET=android CPU_TARGET=arm CROSSOPT=-CfSOFT -Cparmv5t -mfloat-abi=soft CROSSBINDIR=%ANDROID_BIN_ARM% BINUTILSPREFIX=arm-linux-androideabi- Works well. But if I'm using CROSSOPT=-CfVFPV3 -Cparmv7 -mfloat-abi=hard it hangs during compilation of fcl-base: start compiling package fcl-base for target arm-android. Compiling fcl-base\BuildUnit_fcl_base.pp Compiling .\fcl-base\src\ascii85.pp Compiling .\fcl-base\src\avl_tree.pp Compiling .\fcl-base\src\base64.pp Compiling .\fcl-base\src\blowfish.pp Compiling .\fcl-base\src\bufstream.pp Compiling .\fcl-base\src\cachecls.pp Compiling .\fcl-base\src\contnrs.pp Compiling .\fcl-base\src\custapp.pp Compiling .\fcl-base\src\eventlog.pp Compiling .\fcl-base\src\fptimer.pp Compiling .\fcl-base\src\gettext.pp Compiling .\fcl-base\src\idea.pp Compiling .\fcl-base\src\inifiles.pp Compiling .\fcl-base\src\inicol.pp Compiling .\fcl-base\src\iostream.pp Compiling .\fcl-base\src\libtar.pp Compiling .\fcl-base\src\maskutils.pp Compiling .\fcl-base\src\pooledmm.pp and now it hangs. Does not make any difference if targetandroid branch compiler used for the make crossinstall, or the current trunk\. Any clues what I've missed there? Regards, Dennis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] targetandroid - x86 as target cpu
Thomas wrote: Note that if you want to try, some time ago android/x86 compiler support has been added (must add -Cfsse3 though to get valid executables). But one has to specifiy OS_TARGET=linux instead of OS_TARGET=android? Is this correct? Regards, Dennis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] targetandroid - x86 as target cpu
Thomas wrote: Note that if you want to try, some time ago android/x86 compiler support has been added (must add -Cfsse3 though to get valid executables). But one has to specifiy OS_TARGET=linux instead of OS_TARGET=android? Is this correct? make crossinstall OS_TARGET=linux CPU_TARGET=i386 OPT=-Cfsse3 CROSSOPT=-Cfsse3 CROSSBINDIR=%ANDROID_BIN_X86% BINUTILSPREFIX=i686-android-linux- Regards, Dennis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid - x86 as target cpu
Hi, On Tue, 2012-07-31 at 14:20 +0200, Dennis Spreen wrote: Thomas wrote: Note that if you want to try, some time ago android/x86 compiler support has been added (must add -Cfsse3 though to get valid executables). But one has to specifiy OS_TARGET=linux instead of OS_TARGET=android? Is this correct? No, OS_TARGET=android should be specified, although I believe that actually a regular linux compiler (i.e. compiled with OS_TARGET=linux) should work too as long as the rtl is compiled with -Cfvsse3 too. E.g. make crossinstall OS_TARGET=android CPU_TARGET=x86 CROSSOPT=-Cfsse3 CROSSBINDIR=%whatever% BINUTILSPREFIX=i686-linux-androideabi- I saw that I forgot to add and commit the rtl/android/i386 directory. As temporary measure just copy over the files from rtl/linux/i386... :) I will fix that. The x86 android compiler support mostly concerns registration of the target in the compiler and tools, and some modifications to default libraries and fpc.cfg (the latter which I didn't really get around). Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid - can't build for armv7, hangs on pooledmm.pp
Hi, On Tue, 2012-07-31 at 14:20 +0200, Dennis Spreen wrote: I've tested the new targetandroid branch, and by using fpc 2.6.0 and making a new fpcmake (taken from the targetandroid branch), I'm able to compile for armv5: make crossinstall OS_TARGET=android CPU_TARGET=arm CROSSOPT=-CfSOFT -Cparmv5t -mfloat-abi=soft CROSSBINDIR=%ANDROID_BIN_ARM% BINUTILSPREFIX=arm-linux-androideabi- Works well. But if I'm using That's what's mostly been tested and works as you found out. CROSSOPT=-CfVFPV3 -Cparmv7 -mfloat-abi=hard Last time I tried compiling with -Cfvfpv2 or 3 the compiler did not cycle, so I could not test further. Has been some time, and this was native compilation. I think -mfloat-abi does nothing, but maybe that changed recently - there have been many, many changes to the ARM support recently. Further I am actually surprised that there is hardfp support for fpc. If so, it is probably in a somewhat experimental state too. Note that the second android fp ABI is still softfloat, although you can use the vfp registers. I.e. -Cvfpv3(d16) is the only switch you can use, in conjunction with -Cfsoft. (and add -Cparmv7). Note that the other android fp ABI is still softfloat, although you can use the vfp registers. I.e. -Cvfpv3(d16) is the only switch you should use as fp related options. it hangs during compilation of fcl-base: start compiling package fcl-base for target arm-android. Compiling fcl-base\BuildUnit_fcl_base.pp Compiling .\fcl-base\src\ascii85.pp Compiling .\fcl-base\src\avl_tree.pp Compiling .\fcl-base\src\base64.pp Compiling .\fcl-base\src\blowfish.pp Compiling .\fcl-base\src\bufstream.pp Compiling .\fcl-base\src\cachecls.pp Compiling .\fcl-base\src\contnrs.pp Compiling .\fcl-base\src\custapp.pp Compiling .\fcl-base\src\eventlog.pp Compiling .\fcl-base\src\fptimer.pp Compiling .\fcl-base\src\gettext.pp Compiling .\fcl-base\src\idea.pp Compiling .\fcl-base\src\inifiles.pp Compiling .\fcl-base\src\inicol.pp Compiling .\fcl-base\src\iostream.pp Compiling .\fcl-base\src\libtar.pp Compiling .\fcl-base\src\maskutils.pp Compiling .\fcl-base\src\pooledmm.pp and now it hangs. Does not make any difference if targetandroid branch compiler used for the make crossinstall, or the current trunk\. Any clues what I've missed there? At least after removing -mfloat-abi=hard it compiles through here. (make clean crosszipinstall OS_TARGET=android CPU_TARGET=arm CROSSOPT=-Cfvfpv3 -mfloat-abi=soft -Cparmv7 FPC=i386-linux-ppc386 BINUTILSPREFIX=arm-linux-androideabi-) There is another recent compiler switch to pass options to the assembler (you want -march=armv7a to avoid some warnings) to the assembler, but atm I do not remember. Maybe somebody else can help? Note that the targetandroid branch may not support these options yet. I will merge from trunk again soon'ish. Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid - x86 as target cpu
Hi, On Wed, 2012-08-01 at 09:38 +0200, Thomas Schatzl wrote: Hi, On Tue, 2012-07-31 at 14:20 +0200, Dennis Spreen wrote: Thomas wrote: But one has to specifiy OS_TARGET=linux instead of OS_TARGET=android? Is this correct? No, OS_TARGET=android should be specified, although I believe that actually a regular linux compiler (i.e. compiled with OS_TARGET=linux) should work too as long as the rtl is compiled with -Cfvsse3 too. Work in that context means something that runs on an android-x86 device, not necessarily being set up correctly. The x86 android compiler support mostly concerns registration of the target in the compiler and tools, and some modifications to default libraries and fpc.cfg (the latter which I didn't really get around). And setting the correct global defines (e.g. ANDROID instead of LINUX) which is important in some cases. Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] nestedprocvar questions
Am 31.07.2012 22:40, schrieb Craig Peterson:
Hi Sven,
On 7/31/2012 3:11 PM, Sven Barth wrote:
Delphi does not use the @ to designate the function address, so this
isn't to take the address of a function/method. In Delphi you just use
r (in your example).
Normally Delphi doesn't allow assigning local functions to procedure
variables or arguments (just like FPC without 'nestedprocvar'). If the
nested function doesn't access arguments or variables in the outer scope
it generates the stack frame differently and the resulting function is
identical to a standalone non-nested one. You can then use @ to bypass
the typechecking.
Ok... I now tested myself as well using Delphi XE, FPC 2.7.1 (2.6.0
works also) and the following code:
=== source begin ===
program tnested;
{$ifdef fpc}
{$mode delphi}
{$endif}
{$APPTYPE CONSOLE}
type
TFunc = function: LongInt;
procedure DoTest(aFunc: TFunc);
begin
Writeln(aFunc);
end;
procedure Test;
var
t: Integer;
function Test1: LongInt;
begin
Result := 42;
end;
function Test2: LongInt;
begin
Result := t;
end;
begin
DoTest(@Test1);
t := 21;
DoTest(@Test2);
t := 42;
DoTest(@Test2);
end;
begin
Test;
Readln;
end.
=== source end ===
Without the @ the compilation in Delphi indeed fails (it also does in
FPC, but with a different error).
The output of the one compiled with Delphi is the following:
=== output Delphi begin ===
42
4230595
4230595
=== output Delphi end ===
The output of the FPC one is this:
=== output FPC begin ===
42
0
0
=== output FPC end ===
In both cases the output printed by Test2 can be considered garbage and
thus Delphi and FPC behave identical (the value of t in the context of
Test2 is undefined).
What David posted is working Delphi code. We use that style in a few
places to better group and encapsulate procedures for callbacks without
polluting the unit namespace.
Adding nestedprocvar automatically wouldn't change anything as you'd
still need is nested to have a procvar to which nested functions can
be passed to.
The posted code crashes with an EAccessViolation if you run it using
FreePascal's default behavior. Adding {$modeswitch nestedprocvar} and
nothing else makes it work correctly, so there's some change in compiler
behavior even if is nested isn't used.
I now tested exactly David's code and you're right... as far as I can
see this is because nested functions are all marked as delphi style
nested call in case the modeswitch nestedprocvar is set (note: the
access violation might be, because Strings are used and thus
initialization and finalization has to take place).
How exactly do you mean this?
Is the behavior described above (the $modeswitch without is nested)
intentional behavior we can rely on, or an unexpected side effect? Can
it be added to {$MODE DELPHI} to increase Delphi compatibility?
I don't know whether it is intentional behavior as Jonas is the one who
implemented this, but you can open a feature request issue on the
bugtracker where you describe your situation similar to here (with a
stress on Delphi compatiblity ;) ) and then Jonas can decide whether he
enables it for mode Delphi or not (Note: he is currently on vacation, so
it might take a bit longer). And please attach a full compilable example
(that compiles in Delphi in should also compile in FPC (using Delphi mode)).
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid - can't build for armv7, hangs on pooledmm.pp
Thomas Schatzl wrote: Last time I tried compiling with -Cfvfpv2 or 3 the compiler did not cycle, so I could not test further. Has been some time, and this was native compilation. Last I heard cycling goes fine but FPU options don't get passed down to other parts of the build process leading to failures if the selected fpu type does not match the default for the OS and variant in question. I imagine you would have similar problems setting the ABI manually (although I don't know if there is a trap to catch people who do that or if the compiler will carry on blindly doing the wrong thing) I think -mfloat-abi does nothing, but maybe that changed recently - there have been many, many changes to the ARM support recently. Further I am actually surprised that there is hardfp support for fpc. There is hardfloat support in freepascal trunk but unless something has changed recently I doubt a c style -mfloat-abi will activate it. IIRC the fpc option you need for the hardfloat ABI is -CaEABIHF. For linux you can use -dFPC_ARMHF when building the compiler to select the armhf variant which defaults to armv7-a, vfpv3_d16 and hard float abi. If so, it is probably in a somewhat experimental state too. well it works well enough to build the fpc and lazarus debian packages (I backported it to 2.6.0 for debian) and I also ran a fairly thourough test of passing parameters to C code to check they were being passed in the right places. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
