[fpc-pascal] Mozilla XPCOM

José Mejuto joshyfun at gmail.com
Sun Jun 6 19:28:55 CEST 2010


Hello FPC-Pascal,

Friday, June 4, 2010, 2:50:24 PM, you wrote:

>> JM> Maybe you are executing Pascal code in threads that have not been
[...]
>> Not, well, not at least on intention but maybe is the XPCOM which is
>> If that's the case is any kind of workaround ?
JM> No, it cannot be worked around (other than adding functions to the FPC
[...]

I had found the problem, after a lot of debuging and trying to
understand the underlayed COM interface the bug is in the mozilla
XPCOM or in the fpc undertanding of COM interfaces in Linux. Aside the
fact that under safecall in linux fpc does not call
"fpc_safecallcheck" which I think it should be done to test the EAX
register for errors, fpc uses the same exact code under Windows and
Linux but mozilla's XPCOM and I think that finally GCC uses a hybird
calling convention, it is the same as in Linux but the stack must be
cleaned by the caller, not the callee. So the same code to work in
Linux (XPCOM) and in Windows:

asm
    mov eax, [TheCOMInterface];
    mov eax,[eax]
    push Intf;
    push IID;
    push ContractID;
    push TheCOMInterface;
    Call [eax]+16;
{$IFDEF LINUX}
    add esp,16;
{$ENDIF}
    call fpc_safecallcheck;
end;

Which in Linux renders to a "cdecl", but tagging the function as cdecl
crashes because the const parameter TGUID is passed as a 16 bytes
instead one pointer in this declaration:

Original one (Windows):
-----------------------
procedure GetServiceByContractID(const aContractID: PAnsiChar;
                                 const aIID: TGUID;
                                 out _result); safecall;

cdecl that fails (Linux):
-----------------

procedure GetServiceByContractID(const aContractID: PAnsiChar;
                                 const aIID: TGUID;
                                 out _result); cdecl;

cdecl that works as expected (Linux):
-------------------------------------

procedure GetServiceByContractID(const aContractID: PAnsiChar;
                                 const aIID: PGUID;
                                 out _result); cdecl;

Changing the TGUID to PGUID and in the call changing the IID by @IID
it works fine.

Could this be considered a bug in fpc interfaces ? It is expected and
is the XPCOM/GCC the wrong one ? Could or would it be changed in fpc
in a near future ?
                                 
-- 
Best regards,
 José




More information about the fpc-pascal mailing list