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_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to