<html><head></head><body><div>Hi Michalis,</div><div><br></div><div>Thank you for the patch. I failed to test it as I need first to fix pasdoc on sparc64.</div><div>For this, I've installed a QEMU VM which took me two days, but now I'm able to debug it.</div><div><br></div><div>The issue with pasdoc, looks very similar with the issue of CGE with Armel. Not sure it is the very same, but I feel there is a regression in FPC 3.2.2 compared with 3.2.0. This makes me more convinced that we need to keep CGE on all these platforms as it give a good test for the compiler, even if not used at all.</div><div><br></div><div>Below is the results of my investigation:</div><pre>(gdb) r</pre><pre>Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas</pre><pre><br></pre><pre>Breakpoint 3, EXECUTE (this=0x0) at source/component/PasDoc_Base.pas:608</pre><pre>608 ParseFiles;</pre><pre>(gdb) s</pre><pre>PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:472</pre><pre>472 begin</pre><pre>(gdb) </pre><pre>473 FUnits.clear;</pre><pre>(gdb) n</pre><pre>475 DoMessage(1, pmtInformation, 'Starting Source File Parsing ...', []);</pre><pre>(gdb) n</pre><pre>Info[1]: Starting Source File Parsing ...</pre><pre>476 if FSourceFileNames.IsEmpty then Exit;</pre><pre>(gdb) </pre><pre>478 InputStream := nil;</pre><pre>(gdb) </pre><pre>PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:479</pre><pre>479 Count := 0;</pre><pre>(gdb) </pre><pre>PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:480</pre><pre>480 for i := 0 to FSourceFileNames.Count - 1 do</pre><pre>(gdb) </pre><pre>482 p := FSourceFileNames[i];</pre><pre>(gdb) </pre><pre>483 try</pre><pre>(gdb) </pre><pre>Info[2]: Now parsing file testcases/ok_helpinsight_comments.pas...</pre><pre><br></pre><pre>Program received signal SIGBUS, Bus error.</pre><pre>0x000000000025ae50 in REGEXPR$_$TREGEXPR_$__$$_EMITINT$LONGINT ()</pre><pre>(gdb) d</pre><pre>Delete all breakpoints? (y or n) y</pre><pre>(gdb) b PasDoc_Base.pas:483</pre><pre>Breakpoint 4 at 0x13ed5c: file source/component/PasDoc_Base.pas, line 483.</pre><pre>(gdb) r</pre><pre>The program being debugged has been started already.</pre><pre>Start it from the beginning? (y or n) y</pre><pre>Starting program: /home/user/pasdoc-0.16.0/bin/pasdoc --format html --exclude-generator --implementation-comments=join --output=/tmp/pasdoc.log testcases/ok_helpinsight_comments.pas</pre><pre>Info[1]: Starting Source File Parsing ...</pre><pre><br></pre><pre>Breakpoint 4, PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:483</pre><pre>483 try</pre><pre>(gdb) s</pre><pre>490 InputStream := TFileStream.Create(p, fmOpenRead or fmShareDenyWrite);</pre><pre>(gdb) p p</pre><pre>$1 = 0x0</pre><pre>(gdb) p i</pre><pre>$2 = 0</pre><pre>(gdb) p FSourceFileNames[i]</pre><pre>Cannot access memory at address 0xa0</pre><pre>(gdb) p FSourceFileNames</pre><pre>Cannot access memory at address 0xa0</pre><pre>(gdb) p Self</pre><pre>$3 = 0x0</pre><pre>(gdb) bt</pre><pre>#0 PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:490</pre><pre>#1 0x000007fefffea5d8 in ?? ()</pre><pre>Backtrace stopped: previous frame identical to this frame (corrupt stack?)</pre><pre>(gdb) </pre><pre><br></pre><div>As you can see the Self (this pointer in GDB stack trace) is nil (0x0).</div><div>This is probably related to a bug in the stack as suggested by GEB warning.</div><div><br></div><div>I think I need to raise a ticket upstream. What do you think?</div><div>Can you help in suggesting a minimal code to reproduce the issue?</div><pre><span><pre>-- <br></pre><pre>Cheers,
Abou Al Montacir
</pre></span></pre><pre><br></pre><pre>On Thu, 2021-11-11 at 23:47 +0100, Michalis Kamburelis wrote:</pre><pre><div>Looking at your snippet from "fpcsrc/compiler/options.pas", it seems<br></div><div>that CPUSPARC continues to be defined, but only for 32-bit Sparc.<br></div><div><br></div><div>64-bit Sparc defines only CPUSPARC64. I'm not sure was this intended<br></div><div>by FPC developers or not (i.e., did they intend to define CPUSPARC for<br></div><div>both CPUSPARC32 and CPUSPARC64 cases, since otherwise CPUSPARC is just<br></div><div>equivalent to CPUSPARC32 and seems pointless -- but maybe it makes<br></div><div>sense for best backward compatibility). Indeed it seems good to ask<br></div><div>FPC devs about it, and ask for at least update of the docs -- if<br></div><div>everything is as it should be.<br></div><div><br></div><div>For the CGE code, I added there definition of "sparc64" value some<br></div><div>time ago (new allowed value of TCPU in FPC), but I didn't account for<br></div><div>it in "DefaultCPU" definition below. I think that simply adding<br></div><div><br></div><div> {$ifdef CPUsparc64} sparc64 {$endif}<br></div><div><br></div><div>at the end of DefaultCPU definition should be enough. I did it in<br></div><div><a href="https://github.com/castle-engine/castle-engine/commit/4320f4c2a5c6a4fa5b3e530ac378b1f7050eead5">https://github.com/castle-engine/castle-engine/commit/4320f4c2a5c6a4fa5b3e530ac378b1f7050eead5</a><br></div><div>, through I didn't test -- I do actually have access to a Sparc<br></div><div>machine. Let me know does this help :)<br></div><div><br></div><div>Regards,<br></div><div>Michalis<br></div><div><br></div><div>czw., 11 lis 2021 o 11:38 Abou Al Montacir <<a href="mailto:abou.almontacir@sfr.fr">abou.almontacir@sfr.fr</a>> napisał(a):<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Hi Michalis and All,<br></div><div><br></div><div>While I was waiting for Armel compilation, I had a look at other architectures failure and picked my beloved SPARC one.<br></div><div>The failure [1] looks as follows:<br></div><div><br></div><div>Compiling tools/build-tool/code/toolproject.pas<br></div><div>Compiling ./tools/common-code/toolarchitectures.pas<br></div><div>toolarchitectures.pas(129,3) Error: Illegal expression<br></div><div>toolarchitectures.pas(146,3) Error: Illegal expression<br></div><div>toolarchitectures.pas(146,3) Fatal: Syntax error, ";" expected but "identifier DEFAULTOS" found<br></div><div>Fatal: Compilation aborted<br></div><div>Error: /usr/bin/ppcsparc64 returned an error exitcode<br></div><div><br></div><div><br></div><div>It looks like CPUsparc directive has gone and was replaced by sparc or CPUsparc64.<br></div><div>According to the compiler code in fpcsrc/compiler/options.pas:3499<br></div><div> {$ifdef sparc}<br></div><div> def_system_macro('CPUSPARCGEN');<br></div><div> def_system_macro('CPUSPARC');<br></div><div> def_system_macro('CPUSPARC32');<br></div><div> def_system_macro('CPU32');<br></div><div> def_system_macro('FPC_CURRENCY_IS_INT64');<br></div><div> def_system_macro('FPC_COMP_IS_INT64');<br></div><div> {$endif}<br></div><div><br></div><div> {$ifdef sparc64}<br></div><div> def_system_macro('CPUSPARCGEN');<br></div><div> def_system_macro('CPUSPARC64');<br></div><div> def_system_macro('CPU64');<br></div><div> def_system_macro('FPC_CURRENCY_IS_INT64');<br></div><div> def_system_macro('FPC_COMP_IS_INT64');<br></div><div> {$endif}<br></div><div><br></div><div>So do you agree that we should change the define to the new name, even if the official documentation, Table G.2 in [2], does not mention the new directive?<br></div><div><br></div><div>I'll probably raise a ticket on upstream GiLlab so that doc get aligned with code.<br></div><div><br></div><div>[1] <a href="https://buildd.debian.org/status/fetch.php?pkg=castle-game-engine&arch=sparc64&ver=7.0~alpha.1%2Bdfsg-3&stamp=1635791264&raw=0">https://buildd.debian.org/status/fetch.php?pkg=castle-game-engine&arch=sparc64&ver=7.0~alpha.1%2Bdfsg-3&stamp=1635791264&raw=0</a><br></div><div>[2] <a href="https://www.freepascal.org/docs-html/3.2.2/prog/progap7.html">https://www.freepascal.org/docs-html/3.2.2/prog/progap7.html</a><br></div><div><br></div><div>--<br></div><div><br></div><div>Cheers,<br></div><div>Abou Al Montacir<br></div><div><br></div><div>_______________________________________________<br></div><div>Pkg-pascal-devel mailing list<br></div><div><a href="mailto:Pkg-pascal-devel@alioth-lists.debian.net">Pkg-pascal-devel@alioth-lists.debian.net</a><br></div><div><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel</a><br></div></blockquote><div><br></div><div>_______________________________________________<br></div><div>Pkg-pascal-devel mailing list<br></div><div><a href="mailto:Pkg-pascal-devel@alioth-lists.debian.net">Pkg-pascal-devel@alioth-lists.debian.net</a><br></div><div><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel</a><br></div></pre></body></html>