From: Chung-Lin Tang <cltang@linaro.org>
To: David Gilbert <david.gilbert@linaro.org>
Cc: Anthony Green <green@redhat.com>,
libffi-discuss@sourceware.org, Marcus.Shawcroft@arm.com
Subject: Re: [PATCH] Add variadic support
Date: Wed, 23 Feb 2011 16:56:00 -0000 [thread overview]
Message-ID: <4D653C3D.2050107@linaro.org> (raw)
In-Reply-To: <AANLkTimb0T6Ba6SzBCFnAiyjDtMieF2LWAt2g46E5F+o@mail.gmail.com>
On 2011/2/24 12:20 AM, David Gilbert wrote:
> On 23 February 2011 13:25, Chung-Lin Tang <cltang@linaro.org> wrote:
>> On 2011/2/23 09:11 PM, David Gilbert wrote:
>>> In ARM's ffi_prep_cif_machdep I have:
>>>
>>> +#ifdef __ARM_PCS_VFP
>>> + /* VFP uses the standard ABI for variadic functions */
>>> + if ((cif->abi == FFI_VFP) && (cif->nfixedargs != 0))
>>> + cif->abi = FFI_SYSV;
>>> +#endif
>>>
>>> and that's the only active change that's needed.
>>
>> I suggest removing the #ifdef __ARM_PCS_VFP #ifdef. We always have
>> support for both FFI_SYSV and FFI_VFP compiled in, so it doesn't make
>> sense to leave this bit of logic out when we are under __ARM_PCS.
>
> I could do, although cif->nfixedargs is also not present except in the
> VFP case, so
> it would still need an ifdef.
>
> I did that since I thought it best not to change the layout of the CIF
> structure for
> existing ARM builds.
Sigh...you're right about the layout issue :(
Still I think it's best we keep the full FFI_SYSV/VFP capabilities in,
or we'll have the weird case of "FFI_VFP with buggy variadics" under softfp.
I suggest moving the nfixedargs field into the ARM FFI_EXTRA_CIF_FIELDS,
placed after the current VFP fields; this means doing away with the
FFI_TARGET_SPECIFIC_VARIADIC symbol, and probably having a
machine-specific ffi_prep_cif_var_machdep() function, analogous to the
current ffi_prep_cif_machdep().
ffi_prep_cif_var_machdep() can then save things like 'number of fixed
arguments' from the ffi_prep_cif_var() arguments if it is necessary for
that architecture.
Chung-Lin
next prev parent reply other threads:[~2011-02-23 16:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 15:41 Dr. David Alan Gilbert
2011-02-23 12:39 ` Anthony Green
2011-02-23 13:12 ` David Gilbert
2011-02-23 13:26 ` Chung-Lin Tang
2011-02-23 16:20 ` David Gilbert
2011-02-23 16:56 ` Chung-Lin Tang [this message]
2011-02-23 17:21 ` David Gilbert
2011-02-23 17:39 ` Chung-Lin Tang
2011-02-24 6:37 ` Chung-Lin Tang
2011-02-25 12:56 ` David Gilbert
2011-02-25 13:23 ` Chung-Lin Tang
2011-02-25 19:02 ` Anthony Green
2011-02-28 9:08 ` David Gilbert
2011-03-07 18:19 ` David Gilbert
2011-03-16 9:52 ` Chung-Lin Tang
2011-03-16 14:12 ` Anthony Green
2011-03-16 14:25 ` David Gilbert
2011-02-23 21:16 ` PowerPC failures (Was: [PATCH] Add variadic support) Anthony Green
2011-02-24 10:43 ` David Gilbert
2011-02-24 22:37 ` PowerPC failures Anthony Green
2011-02-24 22:41 ` Matthias Klose
2011-02-25 19:18 ` Anthony Green
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D653C3D.2050107@linaro.org \
--to=cltang@linaro.org \
--cc=Marcus.Shawcroft@arm.com \
--cc=david.gilbert@linaro.org \
--cc=green@redhat.com \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).