From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5234 invoked by alias); 13 Nov 2007 22:13:21 -0000 Received: (qmail 5226 invoked by uid 22791); 13 Nov 2007 22:13:20 -0000 X-Spam-Check-By: sourceware.org Received: from vms040pub.verizon.net (HELO vms040pub.verizon.net) (206.46.252.40) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Nov 2007 22:13:18 +0000 Received: from [172.16.1.34] ([72.85.201.226]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JRG004T2TPKI914@vms040.mailsrvcs.net> for gcc-patches@gcc.gnu.org; Tue, 13 Nov 2007 16:12:56 -0600 (CST) Date: Tue, 13 Nov 2007 23:32:00 -0000 From: Timothy Wall Subject: Re: libffi stdcall closures In-reply-to: To: tromey@redhat.com Cc: gcc-patches@gcc.gnu.org Message-id: <9787BB24-EFE3-44B6-A360-F73525AD9170@dev.java.net> MIME-version: 1.0 (Apple Message framework v752.2) X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7bit References: <8269E7B3-A99E-42AC-9314-2613A1C26ABF@users.sf.net> <6F9E5081-D1B5-4D4C-9FC1-D90D22709C9D@dev.java.net> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00756.txt.bz2 On Nov 13, 2007, at 4:08 PM, Tom Tromey wrote: >>>>>> "Timothy" == Timothy Wall writes: > > Timothy> Here's the patch for stdcall closures, including a basic > test. The > Timothy> diff is against the JNA repo; I can probably do one > against a gcc > Timothy> checkout if necessary. > > I'm not really an x86 expert, so perhaps a port maintainer could look > it over. The test case also looked good at first blush, but Andreas > is really the person for that... Should I ping him directly? > > I have a couple nits to pick, but nothing major. > > FWIW there are other areas where you may run into problems. The > biggest one is varargs -- libffi basically doesn't support this at > all. I'm sure there are more obscure ones, too, involving any new ABI > additions... maybe vectors, or decimal float, or I don't know what. Do you mean varargs out or varargs in closures? I'm not too worried about varargs in closures, and varargs calls through libffi seem to work ok in the platforms we've tried so far. > > Timothy> +#ifdef X86_WIN32 > Timothy> + if (cif->abi == FFI_STDCALL) { > Timothy> + FFI_INIT_TRAMPOLINE_STDCALL (&closure->tramp[0], \ > Timothy> + &ffi_closure_STDCALL, \ > Timothy> + (void*)closure, cif- > >bytes); > Timothy> + } > Timothy> +#endif > > You don't need the backslashes here. I see them elsewhere in the > file, but they are bogus. Also the "{" should be on its own line. > > Also, it looks to me as though there's a missing 'else' in > here... shouldn't we call either FFI_INIT_TRAMPOLINE_STDCALL or > FFI_INIT_TRAMPOLINE, but not both? That's just me trying to avoid intersecting conditional code with logic constructs. Following is a better construct, dropping the somewhat useless ASSERTions: > if (cif->abi == FFI_SYSV) > { > FFI_INIT_TRAMPOLINE (&closure->tramp[0], > &ffi_closure_SYSV, > (void*)closure); > } > #ifdef X86_WIN32 > else if (cif->abi == FFI_STDCALL) > { > FFI_INIT_TRAMPOLINE_STDCALL (&closure->tramp[0], > &ffi_closure_STDCALL, > (void*)closure, cif->bytes); > } > #endif > else > { > return FFI_BAD_ABI; > } > I'm looking over the JNA standalone libffi config changes and will post those separately.