From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25738 invoked by alias); 11 Sep 2013 17:03:08 -0000 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 Received: (qmail 25710 invoked by uid 89); 11 Sep 2013 17:03:07 -0000 Received: from mail-pa0-f49.google.com (HELO mail-pa0-f49.google.com) (209.85.220.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 11 Sep 2013 17:03:07 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,MIME_QP_LONG_LINE autolearn=ham version=3.3.2 X-HELO: mail-pa0-f49.google.com Received: by mail-pa0-f49.google.com with SMTP id ld10so9536113pab.22 for ; Wed, 11 Sep 2013 10:02:54 -0700 (PDT) X-Received: by 10.68.254.42 with SMTP id af10mr2954884pbd.154.1378918974813; Wed, 11 Sep 2013 10:02:54 -0700 (PDT) Received: from [10.236.254.228] (161.sub-174-255-160.myvzw.com. [174.255.160.161]) by mx.google.com with ESMTPSA id ia5sm30918864pbc.42.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 10:02:53 -0700 (PDT) References: <1376494321.17852.17.camel@oc8801110288.ibm.com> <20130911113845.GF2643@bubble.grove.modra.org> <1378904143.3730.46.camel@gnopaine> Mime-Version: 1.0 (1.0) In-Reply-To: <1378904143.3730.46.camel@gnopaine> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1204BE32-130D-4F5A-AF7D-70C370855EDE@gmail.com> Cc: Alan Modra , "" , "" , "" From: Jay Subject: Re: [PATCH, PowerPC] Fix PR57949 (ABI alignment issue) Date: Wed, 11 Sep 2013 17:03:00 -0000 To: Bill Schmidt X-IsSubscribed: yes X-SW-Source: 2013/txt/msg00161.txt.bz2 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 wro= te: > 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. >>=20 >> 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 >>=20 >> 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. >=20 > Hm, the libffi case is unfortunate. :( >=20 > 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? >=20 > Thanks, > Bill >=20 >>=20 >> 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? >>=20 >> * src/powerpc/ffi.c (ffi_prep_args64): Align FFI_TYPE_STRUCT. >> (ffi_closure_helper_LINUX64): Likewise. >>=20 >> Index: libffi/src/powerpc/ffi.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- 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; >>=20 >> stacktop.c =3D (char *) stack + bytes; >> gpr_base.ul =3D stacktop.ul - ASM_NEEDS_REGISTERS64 - NUM_GPR_ARG_REGI= STERS64; >> @@ -532,6 +533,10 @@ ffi_prep_args64 (extended_cif *ecif, unsigned long >> #endif >>=20 >> case FFI_TYPE_STRUCT: >> + align =3D (*ptr)->alignment; >> + if (align > 16) >> + align =3D 16; >> + next_arg.ul =3D ALIGN (next_arg.ul, align); >> words =3D ((*ptr)->size + 7) / 8; >> if (next_arg.ul >=3D gpr_base.ul && next_arg.ul + words > gpr_end.u= l) >> { >> @@ -1349,6 +1354,7 @@ ffi_closure_helper_LINUX64 (ffi_closure *closure, >> long i, avn; >> ffi_cif *cif; >> ffi_dblfl *end_pfr =3D pfr + NUM_FPR_ARG_REGISTERS64; >> + unsigned long align; >>=20 >> cif =3D closure->cif; >> avalue =3D alloca (cif->nargs * sizeof (void *)); >> @@ -1399,6 +1405,10 @@ ffi_closure_helper_LINUX64 (ffi_closure *closure, >> break; >>=20 >> case FFI_TYPE_STRUCT: >> + align =3D arg_types[i]->alignment; >> + if (align > 16) >> + align =3D 16; >> + pst =3D ALIGN (pst, align); >> #ifndef __LITTLE_ENDIAN__ >> /* Structures with size less than eight bytes are passed >> left-padded. */ >=20