Re: [cinvoke-dev] i686-pc-mingw32-gcc calling convention

[Dwight Schauer]

Ok, this has nothing to do with the C/invoke library as far as I can
tell. I'm somehow corrupting the Lua context that causes lua_close (L)
to bomb.
I've not yet determined if the problem is in my own code I'm testing
or in the Lua C/Invoke bindings.

On Wed, Jan 19, 2011 at 5:27 PM, Dwight Schauer <address@hidden> wrote:
> Ok, well, I could not get gcc_x86_win to work (functions I'd call
> either do nothing or crash the program no matter what calling
> convention I specified.), so I created a gcc_x86_mingw_cdecl (added a
> an option in the configure script to force an arch).
>
> It is a merge of gcc_x86_unix and gcc_x86_win, cdecl only (I don't
> need the other calling conventions for my project, all I need to
> access is my own project code and occasionally msvcrt.dll, which is
> cdecl and is working fine.
>
> https://bitbucket.org/bogen/cinvoke/changeset/23fc04512f09
>
> Functions I call with that act identically to the way on Linux. (Ran a
> test script from I was running on linux, on windows the output is
> identical using gcc_x86_mingw_cdecl).
> (I'm using Lua).
>
> However, unless I only do very simple stuff, I can't call
> library:dispose () without having my program crash.
>
> The libraries I'm crashing on are the glib and msvcrt dlls.
>
> I've isolated the stuff that is making it crash, but it makes no sense
> as to why those things would cause FreeLibrary(library->dl) to crash
> without returning an error.
>
>
> The code in question involves access to structure references (pointers
> to structures).
>    some_c_struct = cstructure.new (
>      Cint, "a",
>      Cstring, "s",
>      Cint64, "b"
>    )
>
>    some_c_struct_ref = cinv.array (some_c_struct)
>
> The code works fine in Linux, but that functions that operate on that
> with gcc_x86_mingw_cdecl cause FreeLibrary(library->dl) to crash (even
> though they appear to properly pass data back and forth).
>
> I updated the alignments to be the same as gcc_x86_win, but that had no 
> effect.
>
> https://bitbucket.org/bogen/cinvoke/changeset/f4306a0a5218
>
> Anyways, I'll continue digging into it.
>
> --DAS
>
> On Sat, Jan 15, 2011 at 9:34 AM, Will Weisser <address@hidden> wrote:
>> The difference is that ECX and EDX are used to pass parameters in the
>> fastcall calling convention.  If you look at cl_x86_win.c
>> arch_set_register_parms or arch_is_register_parm you can see if the calling
>> convention is not CINV_CC_FASTCALL then the register parameters struct will
>> never get set to anything.   GCC is making the calls using the cdecl
>> convention and so it doesn't need to set those registers, but c/invoke gives
>> up a bit of performance in favor of code simplicity, by having one macro
>> that works in both fastcall and cdecl; in the latter case, the ECX and EDX
>> registers get set to zero but there is no debilitating effect from the
>> called cdecl function's point of view.
>>
>>    -W.W.
>>
>> On Sat, Jan 15, 2011 at 10:08 AM, Dwight Schauer <address@hidden> wrote:
>>>
>>> I added tool prefix functional to configure.pl and the Makefile
>>> templates so that I can cross compile from Linux.
>>>
>>> https://bitbucket.org/bogen/cinvoke/changeset/2e5f387b77aa
>>> https://bitbucket.org/bogen/cinvoke/downloads (tag 1.03c)
>>>
>>> I also made the following two fixes:
>>>
>>> https://bitbucket.org/bogen/cinvoke/changeset/8cc4a9f17c34 Eliminated
>>> printf error for windows (I64 vs ll)
>>> https://bitbucket.org/bogen/cinvoke/changeset/1c1d36f6a300 Eliminated
>>> assembly warning on call indirection
>>>
>>> The issue I have is this:
>>>
>>> ./configure.pl --tool-prefix=i686-pc-mingw32-
>>> Using platform 'X86_WIN'
>>> ...
>>>
>>> Ok, that is fine.
>>>
>>> However, the macro output from gcc_x86_win.h:
>>>
>>> ---< start clip >---
>>> #define ARCH_CALL(regparms, ep) \
>>>        __asm__("mov %0, %%ecx; \
>>>                        mov %1, %%edx; \
>>>                        call *%2" : \
>>>                        : \
>>>                                "m"((regparms).first), \
>>>                                "m"((regparms).second), \
>>>                 "m"(ep));
>>> ---< end clip >---
>>>
>>> cl_x86_win.h appears to be the same, just a different assembler syntax.
>>>
>>> ---< start clip >---
>>> #define ARCH_CALL(regparms, ep) \
>>>        __asm mov ecx, [(regparms).first] \
>>>        __asm mov edx, [(regparms).second] \
>>>        __asm call dword ptr [ep]
>>> ---< end clip >---
>>>
>>>
>>> Neither don't seem to match the calling convention that
>>> i686-pc-mingw32-gcc is laying down:
>>>
>>> ---< start clip >--- // snippets from cinvoke.s
>>>        .loc 1 41 0
>>>        movl    8(%ebp), %eax
>>>        movl    4(%eax), %eax
>>>        movl    %eax, (%esp)
>>>        call    _arch_free_errstr
>>> L2:
>>> ...
>>>        .loc 1 50 0
>>>        movl    $0, 12(%esp)
>>>        movl    $LC0, 8(%esp)
>>>        movl    $0, 4(%esp)
>>>        movl    8(%ebp), %eax
>>>        movl    %eax, (%esp)
>>>        call    _context_set_error
>>>        .loc 1 51 0
>>> ...
>>>        .loc 1 54 0
>>>        movl    $12, (%esp)
>>>        call    _malloc
>>>        movl    %eax, -12(%ebp)
>>> ---
>>>        .loc 1 66 0
>>>        movl    8(%ebp), %eax
>>>        movl    %eax, (%esp)
>>>        call    _free
>>>        .loc 1 67 0
>>> ---< end clip >---
>>>
>>> I'm assuming I'll need to make another arch .h/.c file to match that
>>> calling calling convention, as i686-pc-mingw32-gcc is what I'm using
>>> to target 32 bit windows.
>>>
>>> i686-pc-mingw32-gcc --version
>>> i686-pc-mingw32-gcc (GCC) 4.5.2
>>>
>>> i686-pc-mingw32-gcc -dumpmachine
>>> i686-pc-mingw32
>>>
>>> I'm using http://www.gtk.org/download-windows.html and my cross
>>> compiled programs that link against glib/gtk/etc do work.
>>>
>>> Any thoughts or comments concerning this?
>>>
>>> --DAS
>>>
>