[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
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
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;
478	  InputStream := nil;
PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:479
479	  Count := 0;
PARSEFILES (this=0x0) at source/component/PasDoc_Base.pas:480
480	  for i := 0 to FSourceFileNames.Count - 1 do
482	    p := FSourceFileNames[i];
483	    try
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?)

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?
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
, through I didn't test -- I do actually have access to a Sparc
machine. Let me know does this help :)


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
-------------- 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