[fpc-devel] FPC ARM7 problems

[Jonas Maebe]

On 07 Aug 2014, at 14:09, Sergio Flores wrote:

> 1 - This bug only happens with -O2 on, but with optimizations off  
> the game
> does not crash. I always thought that using optimizations was safe.  
> Can
> there be a compiler bug in the ARM7 codegen?

Not so much in the code generator as in the optimisers. There are a  
lot of ARM peephole optimisations and regularly new bugs are found  
(and fixed) in them. I know of another big project where they also  
cannot compile for ARM with -O2 or they get crashes (and they don't  
have time to isolate the causes).

What you could try with FPC 2.7.1 is -O2 -Oonopeephole, that may give  
you more performance than -O1 and should also be safe. On 2.6.x, that  
won't help because the logic to ensure that -Oonopeephole actually  
disabled peephole optimisations was not implemented there.

> I thought that the bug could be caused by differences in memory  
> allocations
> on those different OSes, but I'm not sure.

The simulator is an x86 program. It does not run ARM code but plain  
i386 code.

> Anyone has a clue how to discover the difference between O2 and O-  
> that
> could cause such problems?

You can start by compiling individual units with different  
optimisations to figure out in which unit a bug is triggered. After  
that, you can put {$optimization off} in that unit after the first,  
second, third, ... procedure to see in which procedure the problem  
occurs.

> 2 - I cannot get line info to work on iOS, all exceptions reported  
> show
> just addresses. I am using -gl so it should work, or it works only  
> in some
> targets?

-gl does has not yet been implemented for DWARF on OS X/iOS. Stabs is  
not supported on iOS, so you indeed cannot get the lineinfo unit to  
work on iOS.

> If not possible to get automatic line info, is there any way to  
> transform
> those adresses into line numbers with some tool?

If the program crashes, the Apple crash reporter should be able to  
read the line info from the debug information. If you just have a  
bunch of addresses from a backtrace generated by the system unit, you  
can use the tool mentioned in the first answer to http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports

> I think in Android the same thing happens, line info not generated  
> when
> using -gl, but I'm not 100% sure (I can check later).

That would be unlikely, because it's basically Linux and on linux -gl  
works with DWARF.

> 3 - Finally, since I'm still using FPC 2.6.2 I decided to upgrade to  
> 2.7.1
> and try to recompile the game, to see if the crash in the game was  
> gone.
> But, with FPC 2.7.2 I simply can't compile the game, it gives errors  
> in the
> assembler stage.
>
> Basically I get lots of errors similar to those
> armv7/MinimonBattle.s:44518:co-processor offset out of range
>
> I checked the asm of the lines in question, it is mostly just a  
> bunch of
> labels, eg:
> Lj21874:
>    .byte    0,0,32,64
> Lj21879:
>    .long    L_U_$MINIMONDB_$$_MOVEINFO$non_lazy_ptr-La1335-8
> Lj21884:
>    .byte    0,0,32,64
>
> Compilation switches are the following:
> -Sgix -Cfvfpv2 -gw2 -gl -O2 -CRriot
>
> The error happens with Cfvfpv3 instead, and with optimizations on or  
> off.
> I'm using latest XCode, by the way.
>
> Anyone has a clue why this happens? Could it be a compiler or  
> assembler bug?

That points to a code generator error in the compiler (or rather a  
layouting error, place the constant too far away from the instruction  
that tries to load it).


Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20140807/fdf6d284/attachment.html>