Hi ! 2013/8/9 livespi <live...@hotmail.com>
> 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 > Tinycc-devel@nongnu.org > 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
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
