Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set.
I'm pretty sure it is getting set because I use it in generating the
assembler command line and i'm using an assembler wrapper that tells me
what the assembler command line is.
Then get the addresses of init_settings.fputype and current_settings.fputype,
and set watchpoints on those to see whether they are still changed somewhere
else. Also set a breakpoint in the code generator somewhere where it should
decide whether to use AFP or VFP instructions,
I'll try but I'm having great trouble understanding how the code
generator works.
I suspect the next thing I actually need to do is come up with a
reduced testcase. The assembler output of system.pp is MASSIVE.
continue and see what goes wrong.
Some other comments about your patch:
* please do not write code like this:
if (target_info.abi <> abi_eabivfp) AND((p.proccalloption in
[pocall_softfloat]) or
(cs_fp_emulation in current_settings.moduleswitches) or
(current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then
Use this instead:
if (target_info.abi <> abi_eabivfp) and
((p.proccalloption in [pocall_softfloat]) or
(cs_fp_emulation in current_settings.moduleswitches) or
(current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then
Ok i'll try and remember that.
* is hard float really only supported on ARMv7-A? There are several ARMv6
platforms that also support VFP.
I belive it is in principle possible to use the hard float ABI with
ARMv6. Not sure if any distro is doing so though. If there are it may
make sense to make ARMv6 the default for an armhf compiler.
* I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines.
Currently the only FPC_ARMHF defines are selecting different defaults.
You should still be able to select either ABI manually with either
compiler binary if you wish.
You can always select the appropriate default ABI via the global configuration
file.
You can but IMO it's neater to have a compiler built to use appropriate
defaults for the system it's running on than to mess with generating and
updating architecture specific configuration files.
* "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi.
But it doesn't use the vfp variant of eabi.....
Something like eabihardfp would be better.
mmm, I mused a bit over that name. It is at least in principle possible
to have EABI variants for FPUs other than vfp. I don't think any
currently exist though and if they do I guess one could always select on
the FPU type. So maybe eabihf or eabihardfloat is indeed a better choice.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
