Re: [Tinycc-devel] When a DLL isn't a DLL.

[Romain ...]

Re !

I've checked with tcc, and it appears that the neither syntax __cdecl nor __stdcall are supported. But tcc features GNU C extension, so the correct code is :

For cdecl
> __attribute__(cdecl) int my_foo(int myArg);

For stdcall
> __attribute__(stdcall) int my_foo(int myArg);

However, you can create __cdecl and __stdcall macros to expand to the correct GNU C syntax.

On Aug 9, 2013 11:06 PM, "Romain ..." <address@hidden> wrote:

Hi !

2013/8/9 livespi <address@hidden>

Greetings all,
Does anyone here have cross-language knowledge/experience with Perl on
Win32?
I can build dll's with tcc using the "-shared" flag, and they work fine
when I  call the dll functions FROM a tcc program.

Perl has a package Win32::API which allows you to call dll functions from
within  a Perl script.  It works fine when calling dll's that come from
Microsoft.   However, when I call my dll's built with tcc, Perl crashes.
>From research on the  web, this indicates an incompatible "calling
convention" i.e. stack arrangement  for function calls. I have to re-build
my dll's with mingw-gcc and dlltool  (which comes with StrawberryPerl)
before I can use them with Perl. This doesn't  make sense to me because
tcc can call MS dll's.

Are the dll's produced by tcc not the same as the dll's from Microsoft?  Is
this  a known issue?  If so, why have the -shared flag at all and just use
a .a or  .lib? I thought tcc was compatible with mingw gcc.

If anyone can shed some light on this I would be grateful.

                        *** WinXP using Popcorn email client



_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Indeed, this is caused by an uncompatible function calling convention.

On the one hand, you have WINAPI functions that use stdcall calling convention (roughly, the stack is cleaned up by the callee itself, that makes more tiny executables)

On the other hand, the c standard library uses the cdecl calling (roughly, the stack is cleaned up by the caller. That allows variadic functions)

I think the issue is that you try to call a cdecl function (that might be tcc's (like any c compiler) default calling convention) using stdcall that causes stacks not be cleaned up, eventually, the program crashes because the call is not cleaned so that the program returns from function at a random adress.

I think the program will also crash if you call a function from the c-runtime library (ie from ``msvcrt.dll'').

The solution is likely to use an __attribute

for cdecl (using gcc)

> __cdecl int foo(...)

for stdcall (using gcc)

> __stdcall int foo(...)

I've heard that the x86-64 windows architectures used an unique calling convention, that looks likes fastcall, but i'm not sure at all

Hope it will help :P