From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23158 invoked by alias); 22 Mar 2012 23:26:09 -0000 Received: (qmail 23051 invoked by uid 22791); 22 Mar 2012 23:26:05 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_BF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.lysator.liu.se (HELO mail.lysator.liu.se) (130.236.254.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Mar 2012 23:25:34 +0000 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AA7B240011 for ; Fri, 23 Mar 2012 00:25:31 +0100 (CET) Received: from peda-pc (h57n3fls301o1095.telia.com [81.230.178.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 8F39640004 for ; Fri, 23 Mar 2012 00:25:30 +0100 (CET) Received: by peda-pc (sSMTP sendmail emulation); Fri, 23 Mar 2012 00:25:38 +0200 From: Peter Rosin To: libffi-discuss@sourceware.org Subject: [PATCH 0/6] MSVC fixes Date: Thu, 22 Mar 2012 23:26:00 -0000 Message-Id: <1332458731-15004-1-git-send-email-peda@lysator.liu.se> X-IsSubscribed: yes Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org X-SW-Source: 2012/txt/msg00137.txt.bz2 Hi! This series fixes a number of problems that MSVC has with libffi. The first patches are pretty mechanic, but the last one adds a new ABI for x86-win32. As it happens, Microsoft and GCC does not agree on the details of the cdecl calling convention when they are returning structures (at least). MS thinks that the caller pops the hidden structure return address and GCC thinks that the callee should do it. And MS relies on the callee to return the structure return address in eax, while GCC seems to not care about that (which is pretty sane, the compiler should be able to keep track och where it did put that structure after all). With the patches the testsuite behaves *much* better for MSVC. What still fails is return_uc.c (crashes, but works when running in the debugger), struct1_win32.c, struct2_win32.c (haven't really looked, they crash) and closure_thiscall.c (no support for using __thiscall from C apparently). And both the C++ tests fail (haven't looked at all). It would be interesting to see if MSVC can call into a libffi built by GCC and vice versa, to check if the structure return discrepancy really is fixed. That should be possible if I did this right, right? Cheers, Peter [PATCH 1/6] Put declarations before statements, C89 style [PATCH 2/6] Add kludge for missing format specifiers on MSVC [PATCH 3/6] Remove surplus frame from MASM function entry [PATCH 4/6] Use __fastcall for MSVC [PATCH 5/6] Translate inline assembly to MSVC format [PATCH 6/6] Add Microsoftian variant of the cdecl ABI