[image: image.png]

When I evaluate the code - it is perfect. However, when I run the code, it raises a SIGSEGV - Segmentation fault. Yet, the code runs perfectly on Linux 64bit machine, and Mac 32bit.

[image: image.png]
Okay, getting debugging... it appears, that 3.0.4 (or Windows) passing a Const Pointer is handled differently?

* The bottom grey line - shows RES = xD9020, however, the LapeOrdChar(show's it's 2nd parameter as 0x0 instead of xD9020). I was originally focusing on Params^[0] - but that is not the error - Result:Pointer is wrong address - even though the calling convention passed in the correct address. ** Again, this is only broken on my Windows compile. I use 2.6.4 on Linux 64bit, and 3.0.4 on Mac (which works) and on Windows. Same compile options (I compile via CLI).

O.

This is 2 decade of development (and for 19 years worked flawlessly) - and in the last 6 months, the windows build is broken. Not sure if it is a 3.0.4 FPC issue, or, a change in the 3.x builds - that I am unaware of.

Alexander, Its the calling line that is messing up.

TLapeImportedFunc(Ptr)(@Stack[StackPos - ParamSize], Res);

* Res has a value before executing that line. However, the called method receives the 2nd param as null.

Or is it in the definition:
TLapeImportedFunc = procedure(const Params: PParamArray; const Result: Pointer); {$IFDEF Using_CDECL}cdecl;{$ENDIF} <-- CDECL is enabled.

So, is a CDECL thing? A compile switch I need to enable/disable? Remove "const" everywhere? ... it has taken me 6 months to slow down and say, WTF. I can run everywhere but Windows. :-(

It's a CDECL thing... :-(

Disabled Using_CDECL, and now the pointer passes to/from the imported functions. (Florian/Jonas/Michael - is this an expected issue on Windows?)

Ozz Nixon schrieb am Sa., 28. Sep. 2019, 22:53:

It would help if you'd provide a self contained example that demonstrates the problem.

Regards,
Sven

I agree - but it is over 2 million lines of code. And disabling CDECL on the windows build of my compiler/interpreter, fixed the issue.

Now, my only problem is when I run the compiler with no parameter it returns back to C:> with a trailing letter. If I trace in FPC.EXE, it does not produce this stray C:>d prompt with a Halt(0).

On Sat, Sep 28, 2019 at 6:35 PM Sven Barth via fpc-devel <

[clip]
By default, Windows uses stdcall calling convention when calling externally defined subroutines in dynamic link libraries. It depends also if the dynamic link library uses stdcall calling convention, too. Other platforms uses cdecl (unix/linux et al).

In your case it may be pascal default one calling convetion.