From: Jay <jay.krell@cornell.edu>
To: Bill Schmidt <wschmidt@linux.vnet.ibm.com>
Cc: Alan Modra <amodra@gmail.com>,
"<gcc-patches@gcc.gnu.org>" <gcc-patches@gcc.gnu.org>,
"<libffi-discuss@sourceware.org>" <libffi-discuss@sourceware.org>,
"<dje@gcc.gnu.org>" <dje@gcc.gnu.org>
Subject: Re: [PATCH, PowerPC] Fix PR57949 (ABI alignment issue)
Date: Wed, 11 Sep 2013 17:03:00 -0000 [thread overview]
Message-ID: <1204BE32-130D-4F5A-AF7D-70C370855EDE@gmail.com> (raw)
In-Reply-To: <1378904143.3730.46.camel@gnopaine>
Isn't mixing and matching and mismatching somewhat inevitable? Libffi & gcc don't always come along with each other? One must never change the ABI?
- Jay
On Sep 11, 2013, at 5:55 AM, Bill Schmidt <wschmidt@linux.vnet.ibm.com> wrote:
> On Wed, 2013-09-11 at 21:08 +0930, Alan Modra wrote:
>> On Wed, Aug 14, 2013 at 10:32:01AM -0500, Bill Schmidt wrote:
>>> This fixes a long-standing problem with GCC's implementation of the
>>> PPC64 ELF ABI. If a structure contains a member requiring 128-bit
>>> alignment, and that structure is passed as a parameter, the parameter
>>> currently receives only 64-bit alignment. This is an error, and is
>>> incompatible with correct code generated by the IBM XL compilers.
>>
>> This caused multiple failures in the libffi testsuite:
>> libffi.call/cls_align_longdouble.c
>> libffi.call/cls_align_longdouble_split.c
>> libffi.call/cls_align_longdouble_split2.c
>> libffi.call/nested_struct5.c
>>
>> Fixed by making the same alignment adjustment in libffi to structures
>> passed by value. Bill, I think your patch needs to go on all active
>> gcc branches as otherwise we'll need different versions of libffi for
>> the next gcc releases.
>
> Hm, the libffi case is unfortunate. :(
>
> The alternative is to leave libffi alone, and require code that calls
> these interfaces with "bad" structs passed by value to be built using
> -mcompat-align-parm, which was provided for such compatibility issues.
> Hopefully there is a small number of cases where this can happen, and
> this could be documented with libffi and gcc. What do you think?
>
> Thanks,
> Bill
>
>>
>> The following was bootstrapped and regression checked powerpc64-linux.
>> OK for mainline, and the 4.7 and 4.8 branches when/if Bill's patch
>> goes in there?
>>
>> * src/powerpc/ffi.c (ffi_prep_args64): Align FFI_TYPE_STRUCT.
>> (ffi_closure_helper_LINUX64): Likewise.
>>
>> Index: libffi/src/powerpc/ffi.c
>> ===================================================================
>> --- libffi/src/powerpc/ffi.c (revision 202428)
>> +++ libffi/src/powerpc/ffi.c (working copy)
>> @@ -462,6 +462,7 @@ ffi_prep_args64 (extended_cif *ecif, unsigned long
>> double **d;
>> } p_argv;
>> unsigned long gprvalue;
>> + unsigned long align;
>>
>> stacktop.c = (char *) stack + bytes;
>> gpr_base.ul = stacktop.ul - ASM_NEEDS_REGISTERS64 - NUM_GPR_ARG_REGISTERS64;
>> @@ -532,6 +533,10 @@ ffi_prep_args64 (extended_cif *ecif, unsigned long
>> #endif
>>
>> case FFI_TYPE_STRUCT:
>> + align = (*ptr)->alignment;
>> + if (align > 16)
>> + align = 16;
>> + next_arg.ul = ALIGN (next_arg.ul, align);
>> words = ((*ptr)->size + 7) / 8;
>> if (next_arg.ul >= gpr_base.ul && next_arg.ul + words > gpr_end.ul)
>> {
>> @@ -1349,6 +1354,7 @@ ffi_closure_helper_LINUX64 (ffi_closure *closure,
>> long i, avn;
>> ffi_cif *cif;
>> ffi_dblfl *end_pfr = pfr + NUM_FPR_ARG_REGISTERS64;
>> + unsigned long align;
>>
>> cif = closure->cif;
>> avalue = alloca (cif->nargs * sizeof (void *));
>> @@ -1399,6 +1405,10 @@ ffi_closure_helper_LINUX64 (ffi_closure *closure,
>> break;
>>
>> case FFI_TYPE_STRUCT:
>> + align = arg_types[i]->alignment;
>> + if (align > 16)
>> + align = 16;
>> + pst = ALIGN (pst, align);
>> #ifndef __LITTLE_ENDIAN__
>> /* Structures with size less than eight bytes are passed
>> left-padded. */
>
next prev parent reply other threads:[~2013-09-11 17:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1376494321.17852.17.camel@oc8801110288.ibm.com>
2013-09-11 11:38 ` Alan Modra
2013-09-11 11:55 ` Jakub Jelinek
2013-09-11 12:56 ` Bill Schmidt
2013-09-11 17:03 ` Jay [this message]
2013-09-12 2:11 ` Alan Modra
2013-09-12 8:33 ` Andrew Haley
2013-09-16 23:38 ` Alan Modra
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=1204BE32-130D-4F5A-AF7D-70C370855EDE@gmail.com \
--to=jay.krell@cornell.edu \
--cc=amodra@gmail.com \
--cc=dje@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=libffi-discuss@sourceware.org \
--cc=wschmidt@linux.vnet.ibm.com \
/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).