[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

[Jonas Maebe]

On 11 Mar 2012, at 14:55, peter green wrote:

> 
>> 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.

Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg).

Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit).

> 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.

Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter.

>> 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.

It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect).


Jonas