From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17696 invoked by alias); 5 Aug 2010 02:51:54 -0000 Received: (qmail 17686 invoked by uid 22791); 5 Aug 2010 02:51:52 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,TW_BF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from corp01.sj.mozilla.com (HELO mail.mozilla.com) (63.245.208.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Aug 2010 02:51:46 +0000 Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id C26D717FC7F4; Wed, 4 Aug 2010 19:51:44 -0700 (PDT) Date: Thu, 05 Aug 2010 02:51:00 -0000 From: Dan Witte To: Timothy Wall Cc: libffi-discuss , Anthony Green Message-ID: <830109349.187251.1280976704717.JavaMail.root@cm-mail03.mozilla.org> In-Reply-To: <485D93F4-737B-4F54-A3AE-767796EB6C31@users.sf.net> Subject: Re: [PATCH] don't count return value space twice on x86 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: 2010/txt/msg00137.txt.bz2 Nope, it's consistent for us. Closure returns an int32_t, building with MSVC on x86 WIN32. If it's working for you, it's likely that you're tickling (or in this case, not tickling) the platform-#ifdefed code in prep_cif. Maybe you have some custom defines or flags (or we're missing them) that cause that? If that code is getting compiled in your builds, then I'm stumped... you are building win32.S with ml, right? Cheers, Dan. ----- Original Message ----- > I take it this is only under *some* circumstances, since I've used a > number of different stdcall closures without issue. > > On Aug 4, 2010, at 8:13 PM, Dan Witte wrote: > > > Anthony, > > > > There's a bug in stdcall x86 WIN32 closure code where stack space > > for the return value is counted twice -- which leads to overpopping > > and a spectacular crash. This adds an X86_ANY define for all x86 > > plats, which simplifies logic and means that stack computation is > > done consistently in the x86 prep_cif_machdep, rather than > > double-counted by prep_cif. > > > > Look OK? > > > > Cheers, > > Dan. > >