<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 07 Aug 2014, at 14:09, Sergio Flores wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">1 - This bug only happens with -O2 on, but with optimizations off the game<br>does not crash. I always thought that using optimizations was safe. Can<br>there be a compiler bug in the ARM7 codegen?<br></span></span></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">I thought that the bug could be caused by differences in memory allocations<br>on those different OSes, but I'm not sure.<br></span></span></blockquote><div><br></div><div>The simulator is an x86 program. It does not run ARM code but plain i386 code.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">Anyone has a clue how to discover the difference between O2 and O- that<br>could cause such problems?<br></span></span></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">2 - I cannot get line info to work on iOS, all exceptions reported show<br>just addresses. I am using -gl so it should work, or it works only in some<br>targets?<br></span></span></blockquote><div><br></div><div>-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.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">If not possible to get automatic line info, is there any way to transform<br>those adresses into line numbers with some tool?<br></span></span></blockquote><div><br></div><div>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 <a href="http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports">http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports</a></div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">I think in Android the same thing happens, line info not generated when<br>using -gl, but I'm not 100% sure (I can check later).<br></span></span></blockquote><div><br></div><div>That would be unlikely, because it's basically Linux and on linux -gl works with DWARF.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="font-family: monospace; ">3 - Finally, since I'm still using FPC 2.6.2 I decided to upgrade to 2.7.1<br>and try to recompile the game, to see if the crash in the game was gone.<br>But, with FPC 2.7.2 I simply can't compile the game, it gives errors in the<br>assembler stage.<br><br>Basically I get lots of errors similar to those<br>armv7/MinimonBattle.s:44518:co-processor offset out of range<br><br>I checked the asm of the lines in question, it is mostly just a bunch of<br>labels, eg:<br>Lj21874:<br> .byte 0,0,32,64<br>Lj21879:<br> .long L_U_$MINIMONDB_$$_MOVEINFO$non_lazy_ptr-La1335-8<br>Lj21884:<br> .byte 0,0,32,64<br><br>Compilation switches are the following:<br>-Sgix -Cfvfpv2 -gw2 -gl -O2 -CRriot<br><br>The error happens with Cfvfpv3 instead, and with optimizations on or off.<br>I'm using latest XCode, by the way.<br><br>Anyone has a clue why this happens? Could it be a compiler or assembler bug?<br></span></span></blockquote><div><br></div><div>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).</div></div><br><div><br></div><div>Jonas</div></body></html>