[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Romain ...
Subject: Re: [Tinycc-devel] When a DLL isn't a DLL.
Date: Fri, 9 Aug 2013 23:06:45 +0200

Hi !

2013/8/9 livespi <address@hidden>
Greetings all,
Does anyone here have cross-language knowledge/experience with Perl on
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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]