Hi all,

I've finally managed to get xpcom/gecko to work (partly) on linux/i386.

The delphi/fpc gecko-headers uses the safecall calling convention a lot.

On Windows a safecall is in principle a stdcall with a 'hidden' function result which contains a value (nsresult) to check if there was any problem during the call of the procedure/function.

I had to find out what calling convention is used by xpcom on Linux. And in fact it's quite logical: it uses cdecl. (As most c-libraries do, use stdcall on Windows, cdecl on others)

So if we want to use xpcom on Linux the same way as on Windows we need a special calling convention which hides the nsresult from the programmer and is compatible with cdecl. We need to have a "cdecl+hidden exception handling" calling convention.

At this moment the 'safecall' calling convention on Linux is undefined. It does exist but has no real meaning. (In fact it is just stdcall, the exception-handling code is only added on Windows by the compiler)

Is it an idea to change the 'safecall' convention on Linux/i386 to be 'cdecl + hidden exception handling' ?

That way we can use xpcom, which you could see as the cross-platform com/activex system, on both Windows and Linux/Unix(?) with the same code. And that's what safecall is for: too easy com/activex programming on Delphi.

Joost

Joost van der Sluis wrote

Is it an idea to change the 'safecall' convention on Linux/i386 to be 'cdecl + hidden exception handling' ?

How Kylix handles the safecall convention on linux? I think we need to follow it.

Best regards,
Paul Ishenin.

I think yes. Since xpcom is the only framework I heard of that uses it, I think it is the logical thing to do.

If later we discover that there are variants of 'safecall' on non-windows, we can change it.

Michael.

In our previous episode, Michael Van Canneyt said:

Agree, trunk is not going gold anyway before the new crossplatform delphi comes out, so if that changes things, we can adapt.

That leaves Paul's correct comments that it would we wise to look what Kylix does.

Well,

Safecall = cdecl for Kylix.

Borland decided to do this instead of giving a compiler error. But since Kylix is long dead, I don't see the need to follow it in this detail. Or do you know a lot of kylix programs/code/libraries out there ?

We have now the opportunity to make something useful of safecall on unix, we should take it. The proposal of Joost is the only sensible option IMHO.

Michael.

See http://bugs.freepascal.org/view.php?id=16685 and the linked discussion from June on the fpc-pascal list.

Jonas

So we can interpret that as a 'yes' :-)

Michael.

Hello Joost,

Wednesday, July 21, 2010, 11:28:55 AM, you wrote:

JvdS> I've finally managed to get xpcom/gecko to work (partly) on linux/i386. JvdS> The delphi/fpc gecko-headers uses the safecall calling convention a JvdS> lot.

I get it to work too, but missing safecall (unix version) makes it unusable as a lot of assembler is needed.

JvdS> On Windows a safecall is in principle a stdcall with a 'hidden' function JvdS> result which contains a value (nsresult) to check if there was any JvdS> problem during the call of the procedure/function. JvdS> I had to find out what calling convention is used by xpcom on Linux. And JvdS> in fact it's quite logical: it uses cdecl. (As most c-libraries do, use JvdS> stdcall on Windows, cdecl on others)

It is not 100% cdecl, const records in safecall must be passed as reference while in cdecl a copy of the record is being passed.

Please check my bug report:
http://bugs.freepascal.org/view.php?id=16685 and some messages in mailing list:

http://lists.freepascal.org/lists/fpc-pascal/2010-June/025605.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025609.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025613.html http://lists.freepascal.org/lists/fpc-pascal/2010-June/025615.html

In the other side, I was unable to make Gecko work correctly (windows) using Gecko > 1.9.1.11 all 1.9.2.x versions raise a bunch of exceptions mostly related to Javascript :( I can run it removing some Javascript initialization scripts and disabling Javascript once loaded. Files needed to be removed:

nsFormAutoComplete.js
nsHelperAppDlg.js
nsProgressDialog.js
nsSearchService.js
nsUpdateService.js

When (if) codegear release the new linux compiler I think they reuse their kylix work. So if we follow the kylix way now we will protect the compiler from the unneeded changes in the future.

Is there a big difference for fpc to call the new calling convention different and map it to safecall on windows?

Best regards,
Paul Ishenin.

That's not true. I managed to get it to work without any assembler. (Only used it to debug and some quick tests)

What you have to do is change definitions like:

function Bla(test: tsometype) : tresulttype; safecall;

to:

function Bla(testl: tsometype; _result: tresulttype) : nsresult;
extdecl;

And define the extdecl macro to stdcall on Windows and cdecl on Linux. Set the nsresult to the right error code to simulate an exception.

I don't think so. The gecko-port-definitions are wrong in this regard. They use 'const' but it should be 'var'. That this worked on Windows was just a coincidence. I've replaced these 'const' parameter definitions to 'var' and now they work on Linux and Windows. The headers just weren't translated right in this regard.

That was a good starting point, to find out what the problem was precisely. Jonas last comment was where I started. But enabling the exception-handling wasn't enough. Using Safecall on Linut, the caller has to clean up the stack (on windows the callee does). I don't know yet how to the latter.

I don't think the parameter-passing should be changed. Just don't use 'const'.

I don't know which version I used. Probably the one from the latest Firefox release. I'll check at home. (tomorrow)

Joost.

I don't think we have to look at Kylix in this regard. When Kylix was released there was no such thing as 'com/activex' on Linux, so the whole safecall thing was useless. Only now there is xpcom it gets a meaning.

Joost

The problem is that then all XPCom headers must be translated

Procedure SomeMethod; {$ifdef windows}safecall{$else}newsafecall {$endif}

Which is a serious pain. I'd prefer then to let safecall be cdecl+exception handling, and in the event that Embarcadero - again - chooses the wrong way, to have a directive:

{$SAFECALLCALLING CDECL}

We have the same for COM/CORBA interfaces, after all.

I think that Linux is FPC territory, it has been for 15 years, and here we should make the rules when on new ground. In this case that means preferring the GCC/G++ way instead of some hypothetical or already proven dead Embarcadero product. In short, it is the logical and obvious choice.

Michael.

Exactly.

Michael.

Michael Van Canneyt wrote

The problem is that then all XPCom headers must be translated Procedure SomeMethod; {$ifdef windows}safecall{$else}newsafecall {$endif}

We have a special macros as I remember for this purposes.

I don't insist on another calling convention (and moreover in real I don't want to have more calling conventions). I'm just trying to show another point of view to find the optimal solution.

Best regards,
Paul Ishenin.

I'll try to patch the compiler so that safecall behaves like cdecl +exceptions on Linux.

If we need more changes later on, or changes for Delphi X compatibility we can add that later. As Marco said, 2.5.1 won't become stable soon so the result is not immediately carved in stone.

Joost.

It is not 100% cdecl, const records in safecall must be passed as reference while in cdecl a copy of the record is being passed.

Copies IMO make no sense here, when "const" protects the record elements from any modifications. That's why a compiler should be free to pass short consts by value, and larger ones (exceeding sizeof(pointer)) by reference.

But of course the definition of the systemwide cdecl and safecall conventions must be observed. When no such definition exists for safecall on a platform, every compiler can define it differently, preventing the use of such procedures in external code (.so).

DoDi

I think that Linux is FPC territory, it has been for 15 years, and here we should make the rules when on new ground. In this case that means preferring the GCC/G++ way instead of some hypothetical or already proven dead Embarcadero product.

The last "compatible" Delphi was D2007, all newer (Unicode) versions are incompatible with FPC. I don't think that we should bother with Delphi "X" compatibility, unless we decide to provide a FPC "Unicode" version or option at all [to come when??? ;-]

DoDi

Hi!

Well... for Linux exists no safecall convention and the only library that might profit from it is XPCOM which uses cdecl procedures that are compatible with the idea of safecall.
But if we implement safecall on Linux to be used with XPCOM then we can't simply define that const records are passed by reference, because the underlying/wrapped calling convention is still cdecl. I myself think of safecall simply as some kind of "syntactic sugar" which makes using (XP)COM easier.

Regards,
Sven

Well... for Linux exists no safecall convention and the only library that might profit from it is XPCOM which uses cdecl procedures that are compatible with the idea of safecall. But if we implement safecall on Linux to be used with XPCOM

...then we might make XPCOM unusable on Windows, when it requires a calling method different from safecall.

DoDi

Hi!

You misunderstand that.

XPCOM uses cdecl on Linux and stdcall on Windows.

The order of the parameters of XPCOM is compatible to the safecall-concept, because the last parameter contains the returned "object" and the return value is a HResult (or nsresult in case of XPCOM).

On Windows safecall is a wrapper around stdcall. On Linux we don't have safecall currently and thus could make it a wrapper around cdecl, because XPCOM uses this on Linux.

Regards,
Sven

Hello Joost,

you wrote

> I get it to work too, but missing safecall (unix version) makes it > unusable as a lot of assembler is needed.

JvdS> That's not true. I managed to get it to work without any assembler. JvdS> (Only used it to debug and some quick tests) JvdS> What you have to do is change definitions like: JvdS> function Bla(test: tsometype) : tresulttype; safecall; JvdS> to:
JvdS> function Bla(testl: tsometype; _result: tresulttype) : nsresult; JvdS> extdecl;

Well, changing interface yes, I avoid to change interface, so stack becomes unbalanced after any function call.

JvdS> And define the extdecl macro to stdcall on Windows and cdecl on Linux. JvdS> Set the nsresult to the right error code to simulate an exception.

I was trying to not touch interface and as my request about safecall in unix was "accepted" for a future discussion, I do not investigate further. Already spend a lot of time trying to figure why "safecall" works different in unix and in Windows... The silently replace calling convention confuses me :(

> It is not 100% cdecl, const records in safecall must be passed as > reference while in cdecl a copy of the record is being passed.

JvdS> I don't think so. The gecko-port-definitions are wrong in this regard. JvdS> They use 'const' but it should be 'var'. That this worked on Windows was JvdS> just a coincidence. I've replaced these 'const' parameter definitions to JvdS> 'var' and now they work on Linux and Windows. The headers just weren't JvdS> translated right in this regard.

Even if declarations in the code are wrong (which I had not checked, I assumed they were fine) the "const" behavior with record in Windows safecall and linux cdecl is different. Also parameters not intented to be modified should not be var but const (IMHO).

JvdS> That was a good starting point, to find out what the problem was JvdS> precisely. Jonas last comment was where I started. But enabling the JvdS> exception-handling wasn't enough. Using Safecall on Linut, the caller JvdS> has to clean up the stack (on windows the callee does). I don't know yet JvdS> how to the latter.
JvdS> I don't think the parameter-passing should be changed. Just don't use JvdS> 'const'.

I think if it is named safecall is must match windows safecall. Maybe better use "xpcom" or "unixsafecall" ? Parameter passing mode should match at all, callee or caller clean up is transparent to the people working with the library or other library, but how parameters are passed could bring a lot of confusion.

JvdS> I don't know which version I used. Probably the one from the latest JvdS> Firefox release. I'll check at home. (tomorrow)

I was using my modified version in the gecko port CCR, which fixes some bugs, maybe I had introduced new ones ?

Offcourse the behaviour is different for a different calling convention and OS. That's perfectly normal. If all calling conventions were the same, we woudn't have them.

Fact is that the person who wrote these headers thought that 'const' could be used to pass parameters by reference. Too bad that he/she was wrong. That it worked (only on windows/32 bit) is fine for him/her, but not for us. (Probably he/she didn't care as it worked on Delphi only)

Also parameters not intented to be modified should not be var but const (IMHO).

Well, problem is that maybe you defined them as 'const', the underlying c-library just defined them as *record. So it *can* change. const is misleading.

Being compatible with some windows-thing on Linux is useless.

Joost

Hello Joost,

you wrote

> Even if declarations in the code are wrong (which I had not checked, I > assumed they were fine) the "const" behavior with record in Windows > safecall and linux cdecl is different.

JvdS> Offcourse the behaviour is different for a different calling convention JvdS> and OS. That's perfectly normal. If all calling conventions were the JvdS> same, we woudn't have them.

Yes, but I think, maybe I'm wrong, that a cdecl declaration in any platform matches the same behavior in other platform. This means that:

procedure (a: pointer); cdecl;

is expected to produce the same effect (not internal implementation) in any platform. So:

procedure (const a: record); safecall;

in Unix will produce a copy of "a" and in Windows a reference to "a" which is not very portability friendly.

Anyway I think the problem is on the XPCOM guys, as they decide to "define" safecall with different meanings in different platforms, so in Windows it is "stdcall safecall" and in Unix "cdecl safecall" (safecall referenced to the postprocessing of nsResult).

To me it smells like everything was designed in Linux and later they decide to mimic the Windows Activex in the windows world.

Anyway whichever you decide is OK to me.

José Mejuto wrote

procedure (a: pointer); cdecl; is expected to produce the same effect (not internal implementation) in any platform.

Well, no. It is expected to produce the same effect as the C compilers on every platform. These may behave differently amongst different platforms.

In Windows it currently only passes "a" by reference if the size of the record is > sizeof(pointer).

Jonas

No. Most platforms also don't have multiple calling conventions, so the only calling convention would map to cdecl, since that would be the one that the c compilers will use.

Henry

Hello FPC,

you wrote

> is expected to produce the same effect (not internal implementation) > in any platform.

JM> Well, no. It is expected to produce the same effect as the C JM> compilers on every platform. These may behave differently amongst JM> different platforms.

So it is reasonable and "logical" that stdcall in platform A passes parameters from left to right and in platform B passes them right to left ? even called in both stdcall ? (stdcall in example).

Maybe move this to fpc-pascal ?

> procedure (const a: record); safecall; > in Unix will produce a copy of "a" and in Windows a reference to "a"

JM> In Windows it currently only passes "a" by reference if the JM> size of the record is > sizeof(pointer).

I was trying to simplify the idea without the details.

Hi!

I think you (and some others) got something wrong here.

Safecall is a Borland invention and only available in Delphi to simplify COM development (see
http://en.wikipedia.org/wiki/X86_calling_conventions#safecall ). The XPCOM guys don't have anything to do with this. They defined all methods as stdcall on Windows (as expected on that platform) and as cdecl on Linux (also as expected by the platform). Delphi's/FPC's safecall on Windows is simply a wrapper around a normal stdcall procedure/function/method that throws an exception if the result value contains an error (it's an HResult). On all other platforms it's equal to the default calling convention (register on i386, cdecl on everything else).

So it's perfectly legal for us to define safecall on Linux (which doesn't use safecall in any way) as an "exception throwing wrapper" around cdecl. The only obstacle here might be the new cross plattform compiler from Embarcadero, but that lies in the (though maybe not so far) future.

Regards,
Sven

Safecall is a Borland invention and only available in Delphi to simplify COM development

AFAIK SafeCall and SafeArray are Microsoft inventions, in the introduction of OLE/COM. Borland had to understand and implement the related functionality in the language and compiler.

DoDi

Hello FPC,

you wrote

> To me it smells like everything was designed in Linux and later they > decide to mimic the Windows Activex in the windows world. > Anyway whichever you decide is OK to me.

SB> I think you (and some others) got something wrong here.

The wrong thing is that I was thinking that a calling convention was a strict set of rules to pass parameters and call functions, but it seems to be a set of rules per platform even using the same processor.

If I were right, safecall must be stdcall+exception in both platforms, which it is not the case.

I know safecall is a Borland idea, but it is documented as stdcall+exception, not as cdecl+exception.

I do not know if you can catch my point of view. In the other hand I'm not against calling it safecall due the XPCOM compatibility (I had already requested it in the bug report).