FPC 3 - Constructors doesn't work from script

[gustaf68]

In FPC 3.0 and higher, calling constructors from a script doesn't work anymore. Reverting to FPC 2.6.4 (Lazarus 1.4) makes the script work again. I reported this to Lazarus bugtracker and was suggested some code in PascalScript needs to be changed:

"You should file a bug report against PascalScript. It relies on assumptions about the code generation, which we cannot support nor can guarantee to remain unchanged across releases."

There is a demo at the bugreport that shows the error: https://bugs.freepascal.org/view.php?id=31234

However, if the objects are created within the main program it works to access and use them from the script. At the Lazarus forum, user Derek Evans came up with a workaround that might be of help understanding how to resolve this bug: http://forum.lazarus-ide.org/index.php?topic=33302.msg215566#msg215566

I got a thought, that this might be a sideeffect of the FPC 3 changes regarding strings.

A Lazarus project of mine depends on PascalScript and I would be grateful if someone could look at this.

[carlokok]

Is this with latest PascalScript (from this repository?) there were contributed patches for FPC3.0 that touch the constructor logic like https://github.com/remobjects/pascalscript/pull/134/files.

[gustaf68]

Hi Carlo, thanks for the reply. Yes, latest PascalScript from here. Today I tested some more, and if the app is compiled as 32bits it works for both Linux and Windows. What do you think needs to be done to make the script work for 64bits apps?

[gustaf68]

The crash happens in x64.inc, at CALL RAX by the red breakpoint in the picture. I don't know assembler so I can't fix it. By the way, could the ASM be replaced by pascal code instead, or does it have to be assembler? Sorry if that's a silly question. :)

[pult]

For x64, a replacement to "pascal" is possible. This works without failures (GPF) when an "exception" occurs ( fpc not implement asm ".params" ). Sample: https://github.com/pult/pascalscript/blob/fix_20170321_x64call/Source/x64.inc

[gustaf68]

Thanks pult, I'm checking it out. Found the enabling code:

{$DEFINE X64CALL_ASM} { optional } // TODO: Check pas version (disable "X64CALL_ASM").

After disabling X64CALL_ASM I tried compiling but got Error because the code tries to use another TRegisters that doesn't have all the members like _RSI and so on. I found the second TRegisters and will test more tomorrow.

Compile errors:

[gustaf68]

The code has many procedural pointers like t_pcall_04. Perhaps they could be replaced by using a single open array? Open arrays can take an unknown number of arguments. Then just loop through the array and process it.

t_pcall = procedure(RegValue: Array of IPointer);

https://www.freepascal.org/docs-html/ref/refsu68.html

I'm also curious why does it start with t_pcall_04 and not t_pcall_01 ?

Will study the code some more.

[carlokok]

@gustaf68 it doesn't work that way. The asm function we use builds the stack given input parameters, an array parameter isn't compatible with that. Thats why @pult's version has all the different versions, he must have variations for all possibilities.

The real fix would be to find out what changed in FreePascal for constructors (again for the so manyth time) and do the same change in PascalScript.

[gustaf68]

@carlokok I will try to find out the constructor change then. But then you don't think it has anything to do the new fpc string management?

[carlokok]

I don't think it has much to do with string management since the constructor you call in the referenced bugreport doesn't have string parameters.

[gustaf68]

I'm compiling old fpc revisions to find the change in code. Might take a few days, we'll see.

[gustaf68]

Found it! FPC rev. 26683 contains the changes that broke constructors in 64bit pascalscript. How do we take it from here?

---

r26683 | sergei | 2014-02-06 13:26:47 +0100 (Thu, 06 Feb 2014) | 2 lines
Changed paths:
M /trunk/compiler/ncal.pas
M /trunk/compiler/psub.pas

• Changed passing of hidden parameters to constructors of class-style objects: VMT is always passed in the first ('self') parameter, and the second one ('vmt', although this name is now misleading) contains flag specifying the constructor behavior and meaning of 'self'. Together with r26656 this removes methodpointer sharing between two parameter node trees, it becomes possible not to put methodpointer into temp, but use node tree below 'self' parameter to do virtual calls. This also matches behavior of Delphi.

---

Here's the console program I used to test revisons with.

program fptest;

{$mode objfpc}{$H+}

uses
  Crt, Classes, SysUtils, uPSRuntime, uPSComponent, uPSComponent_Default,
  Types,typinfo,rtlconsts,

  uPSC_std, uPSR_std, uPSC_classes, uPSR_classes;

var
  sl: TStringList;
  PSImport_Classes: TPSImport_Classes;
  PSScript: TPSScript;
  i:integer;
begin
  ClrScr;

  PSScript:= TPSScript.Create(nil);
  PSImport_Classes:= TPSImport_Classes.Create(nil);
  TPSPluginItem(PSScript.Plugins.Add).Plugin := PSImport_Classes;

  sl:= TStringList.Create;
  sl.Add('var');
  sl.Add('  sl: TStringList;');
  sl.Add('begin');
  sl.Add('  sl:= TStringList.Create;');
  sl.Add('  sl.Add(''Test'');');
  sl.Add('  sl.Free;');
  sl.Add('end.');

  PSScript.Script := sl;

  writeln('Attempting to compile the pascalcript...');

  if PSScript.Compile then
  begin
    writeln('Pascalscript compiled successfully!');
    if PSScript.Execute then
    begin
      writeln('Pascalscript executed successfully!');
    end
    else
    begin
      writeln('Executing the pascalscript failed!');
      Exit;
    end
  end
  else
  begin
    writeln('Compile didn''t work..');
    for i:= 0 to PSScript.CompilerMessageCount-1 do
    begin
      writeln(PSSCript.CompilerMessages[i].MessageToString);
    end;
  end;
//  readln;
end.

[carlokok]

Have a look at this:
https://github.com/remobjects/pascalscript/blob/master/Source/uPSRuntime.pas#L10259

I added that code because FPC had things in reverse; try commenting the whole ifdef FPC out.

[gustaf68]

Carlo, I commented out the IFDEF, but it didnt work with only that:

Result from Lazarus running a test program:

[gustaf68]

Unfortunately I'm not very good at pointers, but is there a reason Ext1 is referenced without a '^' and Ext2 is not? Tried adding the ^ but it didn't matter.

function TPSExec.RegisterFunctionName(const Name: tbtString; ProcPtr: TPSProcPtr; Ext1, Ext2: Pointer): PProcRec;
var
  p: PProcRec;
  s: tbtString;
begin
  s := FastUppercase(Name);
  New(p);
  p^.Name := s;
  p^.Hash := MakeHash(s);
  p^.ProcPtr := ProcPtr;
  p^.FreeProc := nil;
  p.Ext1 := Ext1; 
  p^.Ext2 := Ext2;
  FRegProcs.Add(p);
  Result := P;
end;

[Alekcvp]

New delphi compilers automatically treat PRec.Field as PRec^.Field, so it's equal
(except for "with PRec^ do ...").