[fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

Nikolay Nikolov nickysn at gmail.com
Sat Apr 1 03:32:35 CEST 2023

On 3/31/23 01:19, Michalis Kamburelis via fpc-devel wrote:
> Thanks for the answers,
> I have submitted issue
> https://gitlab.com/freepascal.org/fpc/source/-/issues/40229 describing
> how to reproduce the problem.

I think I fixed it. At least compilation now continues and fails later, 
due to lack of goto support, so this particular bug should be fixed.


> Hopefully it can get some attention :) I would very much like to add
> "web" target to CGE, to be able to just run CGE games in a browser.
> It's going to be my highest-priority thing after upcoming CGE 7.0
> release.
> Regards,
> Michalis
> czw., 30 mar 2023 o 21:11 Nikolay Nikolov via fpc-devel
> <fpc-devel at lists.freepascal.org> napisał(a):
>> On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote:
>>> Hi,
>>> We're experimenting with compiling Castle Game Engine using FPC
>>> WebAssembly target.
>>> A lot of units and classes compiled smoothly, however we hit a weird
>>> bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors
>>> "Wasm32 symbol xxx without index value error" at the code trying to
>>> use various property setters or methods. Examples:
>>> x3dcamerautils.pas(344,0) Error: Wasm32 symbol
>>> value error
>>> // where TSFRotation.Value is a property with record type, with getter
>>> and setter methods
>>> x3dcamerautils.pas(344,0) Error: Wasm32 symbol
>>> without index value error
>>> // where TX3DSimpleMultField.GetItems is a method of a generic class)
>>> x3dcamerautils.pas(344,0) Error: Wasm32 symbol
>>> X3DFIELDS$_$TSFFLOAT_$__$$_SETVALUE$SINGLE without index value error
>>> x3dcamerautils.pas(344,0) Error: Wasm32 symbol
>>> // where TSFFloat.SetValue is a simple setter for a Single property, no generics
>>> castlescenecore.pas(8822,0) Error: Wasm32 symbol
>>> without index value error
>>> // where TShapeShadowVolumes.PrepareResources is a simple method,
>>> without any parameters, in a simple non-generic class
>>> Weirder, on another machine, the symbols reported contain some exe
>>> filenames at the place of initial "$_$" (maybe independent compiler
>>> bug at message display?):
>>> x3dloadinternalgeo.pas(234,0) Error: Wasm32 symbol
>>> X3DFIELDS/usr/bin/dbus-update-activation-environmentTSFFLOAT_$__$$_SETVALUE$SINGLE
>>> without index value error
>>> x3dloadinternalgeo.pas(234) Error: Wasm32 symbol
>>> X3DFIELDS/home/michalis/bin/castle-engineTSFFLOAT_$__$$_SETVALUE$SINGLE
>>> without index value error
>>> Sometimes the errors can be workarounded by some simple actions --
>>> like moving the property getter/setter protected->private, or avoiding
>>> the call to that particular method. But the solutions, as well as
>>> causes, seem ~random from our perspective. And all in all, we didn't
>>> finish the compilation of X3DNodes unit because after each
>>> fix/workaround/hack for a specific case, another similar error pops
>>> up.
>>> Grepping FPC for the asmw_e_illegal_unset_index (this is "Wasm32
>>> symbol $1 without index value error"), the error can occur when symbol
>>> cannot be found in the list where compiler expected it to be.
>>> We don't have any simple bugreport about it (yet), as the error really
>>> manifests only in a big unit, that is interconnected with a few other
>>> big units. Isolating the testcase (and/or doing much needed refactor
>>> of this unit :) ) will take a while.
>>> Does anyone have a hint:
>>> - What does this error really mean? What is internally wrong at
>>> compilation to cause it? What could be the culprit?
>>> - Is there some universal workaround for it (on CGE side) or fix on
>>> the compiler side?
>>> Even a vague hint could at least help us prepare an isolated
>>> bugreport, because otherwise we have a rather big chunk of code to
>>> dissect in order to provide a simple FPC testcase :)
>> Even a big unit is fine for a bug report, as long as all the code is
>> publicly available for download. If you can't seem to get it to
>> reproduce with a small test case, you can mention in the bug report that
>> you tried, but didn't succeed and still provide the full code needed.
>> AFAIK, the Castle Game Engine is open-source, so this shouldn't be a
>> problem?
>> Nikolay
>>> Regards,
>>> Michalis
>>> _______________________________________________
>>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

More information about the fpc-devel mailing list