[Pkg-pascal-devel] Castle Game Engine build failure on sparc64.
Abou Al Montacir
abou.almontacir at sfr.fr
Fri Nov 12 18:58:29 GMT 2021
Hi Michalis,
Thank you for the patch. I failed to test it as I need first to fix pasdoc on
sparc64.
For this, I've installed a QEMU VM which took me two days, but now I'm able to
debug it.
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.
Below is the results of my investigation:
(gdb) r
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
Breakpoint 3, EXECUTE (this=0x0) at source/component/PasDoc_Base.pas:608
608 ParseFiles;
(gdb) s
PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:472
472 begin
(gdb)
473 FUnits.clear;
(gdb) n
475 DoMessage(1, pmtInformation, 'Starting Source File Parsing ...', []);
(gdb) n
Info[1]: Starting Source File Parsing ...
476 if FSourceFileNames.IsEmpty then Exit;
(gdb)
478 InputStream := nil;
(gdb)
PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:479
479 Count := 0;
(gdb)
PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:480
480 for i := 0 to FSourceFileNames.Count - 1 do
(gdb)
482 p := FSourceFileNames[i];
(gdb)
483 try
(gdb)
Info[2]: Now parsing file testcases/ok_helpinsight_comments.pas...
Program received signal SIGBUS, Bus error.
0x000000000025ae50 in REGEXPR$_$TREGEXPR_$__$$_EMITINT$LONGINT ()
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) b PasDoc_Base.pas:483
Breakpoint 4 at 0x13ed5c: file source/component/PasDoc_Base.pas, line 483.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
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
Info[1]: Starting Source File Parsing ...
Breakpoint 4, PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:483
483 try
(gdb) s
490 InputStream := TFileStream.Create(p, fmOpenRead or fmShareDenyWrite);
(gdb) p p
$1 = 0x0
(gdb) p i
$2 = 0
(gdb) p FSourceFileNames[i]
Cannot access memory at address 0xa0
(gdb) p FSourceFileNames
Cannot access memory at address 0xa0
(gdb) p Self
$3 = 0x0
(gdb) bt
#0 PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:490
#1 0x000007fefffea5d8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
As you can see the Self (this pointer in GDB stack trace) is nil (0x0).
This is probably related to a bug in the stack as suggested by GEB warning.
I think I need to raise a ticket upstream. What do you think?
Can you help in suggesting a minimal code to reproduce the issue?
--
Cheers,
Abou Al Montacir
On Thu, 2021-11-11 at 23:47 +0100, Michalis Kamburelis wrote:
Looking at your snippet from "fpcsrc/compiler/options.pas", it seems
that CPUSPARC continues to be defined, but only for 32-bit Sparc.
64-bit Sparc defines only CPUSPARC64. I'm not sure was this intended
by FPC developers or not (i.e., did they intend to define CPUSPARC for
both CPUSPARC32 and CPUSPARC64 cases, since otherwise CPUSPARC is just
equivalent to CPUSPARC32 and seems pointless -- but maybe it makes
sense for best backward compatibility). Indeed it seems good to ask
FPC devs about it, and ask for at least update of the docs -- if
everything is as it should be.
For the CGE code, I added there definition of "sparc64" value some
time ago (new allowed value of TCPU in FPC), but I didn't account for
it in "DefaultCPU" definition below. I think that simply adding
{$ifdef CPUsparc64} sparc64 {$endif}
at the end of DefaultCPU definition should be enough. I did it in
https://github.com/castle-engine/castle-engine/commit/4320f4c2a5c6a4fa5b3e530ac
378b1f7050eead5
, through I didn't test -- I do actually have access to a Sparc
machine. Let me know does this help :)
Regards,
Michalis
czw., 11 lis 2021 o 11:38 Abou Al Montacir <abou.almontacir at sfr.fr> napisał(a):
>
> Hi Michalis and All,
>
> While I was waiting for Armel compilation, I had a look at other architectures
> failure and picked my beloved SPARC one.
> The failure [1] looks as follows:
>
> Compiling tools/build-tool/code/toolproject.pas
> Compiling ./tools/common-code/toolarchitectures.pas
> toolarchitectures.pas(129,3) Error: Illegal expression
> toolarchitectures.pas(146,3) Error: Illegal expression
> toolarchitectures.pas(146,3) Fatal: Syntax error, ";" expected but "identifier
> DEFAULTOS" found
> Fatal: Compilation aborted
> Error: /usr/bin/ppcsparc64 returned an error exitcode
>
>
> It looks like CPUsparc directive has gone and was replaced by sparc or CPUspar
> c64.
> According to the compiler code in fpcsrc/compiler/options.pas:3499
> {$ifdef sparc}
> def_system_macro('CPUSPARCGEN');
> def_system_macro('CPUSPARC');
> def_system_macro('CPUSPARC32');
> def_system_macro('CPU32');
> def_system_macro('FPC_CURRENCY_IS_INT64');
> def_system_macro('FPC_COMP_IS_INT64');
> {$endif}
>
> {$ifdef sparc64}
> def_system_macro('CPUSPARCGEN');
> def_system_macro('CPUSPARC64');
> def_system_macro('CPU64');
> def_system_macro('FPC_CURRENCY_IS_INT64');
> def_system_macro('FPC_COMP_IS_INT64');
> {$endif}
>
> 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?
>
> I'll probably raise a ticket on upstream GiLlab so that doc get aligned with c
> ode.
>
> [1] https://buildd.debian.org/status/fetch.php?pkg=castle-game-engine&arch=sp
> arc64&ver=7.0~alpha.1%2Bdfsg-3&stamp=1635791264&raw=0
> [2] https://www.freepascal.org/docs-html/3.2.2/prog/progap7.html
>
> --
>
> Cheers,
> Abou Al Montacir
>
> _______________________________________________
> Pkg-pascal-devel mailing list
> Pkg-pascal-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel
_______________________________________________
Pkg-pascal-devel mailing list
Pkg-pascal-devel at alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-pascal-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20211112/1f284146/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-pascal-devel/attachments/20211112/1f284146/attachment.sig>
More information about the Pkg-pascal-devel
mailing list