From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 48DDB385740E for ; Thu, 10 Jun 2021 02:39:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 48DDB385740E Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15A2XILg129384; Wed, 9 Jun 2021 22:39:06 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 393956hdgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Jun 2021 22:39:06 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 15A2XXDG020892; Thu, 10 Jun 2021 02:39:05 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma01dal.us.ibm.com with ESMTP id 3900w9wng8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Jun 2021 02:39:05 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 15A2d4a931326662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Jun 2021 02:39:04 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A3AF012405A; Thu, 10 Jun 2021 02:39:04 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6769D124055; Thu, 10 Jun 2021 02:39:04 +0000 (GMT) Received: from mww0171.wdc07m.mail.ibm.com (unknown [9.208.70.164]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 10 Jun 2021 02:39:04 +0000 (GMT) In-Reply-To: To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org Message-ID: From: "Cheng Jin" Date: Wed, 9 Jun 2021 22:39:00 -0400 Content-type: multipart/related; Boundary="0__=8FBB0C63DF9F42758f9e8a93df938690918c8FBB0C63DF9F4275" References: X-KeepSent: 02C799C9:BD590CCF-002586F0:000CC4E5; name=$KeepSent; type=4 X-Mailer: IBM Notes Release 10.0.1 November 29, 2018 X-Disclaimed: 35091 X-MIMETrack: CD-MIME by Router on MWW0171/01/M/IBM at 06/10/2021 02:39:04, CD-MIME complete at 06/10/2021 02:39:04,Itemize by Router on MWW0171/01/M/IBM at 06/10/2021 02:39:04 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 3-hUZzag-wbzBKeXV6Smx9fBsaDixLVK X-Proofpoint-ORIG-GUID: 3-hUZzag-wbzBKeXV6Smx9fBsaDixLVK X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 Subject: RE: Incorrect data detected in the nested float struct with x86/libffi on Linux/64bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-09_14:2021-06-04, 2021-06-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 spamscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106100014 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TVD_FW_GRAPHIC_NAME_MID, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 02:39:16 -0000 --0__=8FBB0C63DF9F42758f9e8a93df938690918c8FBB0C63DF9F4275 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Kaz, It is highly likely that the version of libffi coming with Ubuntu 18 is outdated (we experienced the same abort with an outdated x86/libffi integrated in our own project). Please try the latest version of x86/libffi at https://github.com/libffi/libffi/tree/master/src/x86. In addition, adding padding to the nested structure might work but doesn't make any sense as ffi_prep_cif() will detect/compute the padding automatically in the code, in which case everything related to padding should be handled by libffi rather than by users. That's why they need to investigate why it failed to handle on Linux/64bit given it works good on other platforms (e.g. Windows/x86_64, Aarch64). Thanks and Best Regards Cheng Jin From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> To: Cheng Jin Cc: libffi-discuss@sourceware.org Date: 2021-06-09 10:05 PM Subject: [EXTERNAL] Re: Incorrect data detected in the nested float struct with x86/libffi on Linux/64bit On 2021-06-09 09:41, Cheng Jin via Libffi-discuss wrote: > Hi, > > We found that the nested struct [[float, float], float] works good with > x86/libffi (at https://github.com/libffi/libffi/tree/master/src/x86 ) > on Linux/64bit (verified on Ubuntu 19) while a variant of it like > [float,[float,float]] was messed up at the 3rd element when invoking > ffi_call() in the following test: In the libffi that comes with Ubuntu 18.04 Server, x84-64, your test case aborts in ffi_call. I built a similar test case in which I put your function into a shared lib, and used a libffi-based programming language to call it. Same thing: abort in ffi_call. There is some problem in that version of libffi; it doesn't like small structures. If I add padding to the structure, then there is no abort. My version of the function looks like this: float_t testNestedFloatStruct(float_t arg1, stru_Nested_F arg2) { float_t floatSum =3D arg1 + arg2.elem1 + arg2.elem2.elem1 + arg2.elem2.elem2; puts("called"); printf("arg1 =3D %f, arg2 =3D { %f, { %f, %f } }\n", arg1, arg2.elem1, arg2.elem2.elem1, arg2.elem2.elem2); return floatSum; } On the FFI side, if I add a uint64's worth of padding to the structure, the ffi_call proceeds without abort, and the result is like this: arg1 =3D 1.000000, arg2 =3D { 0.000000, { 0.000000, -52784298695107543040.000000 } } -5.27842986951075e19 The second line is the caller printing the return value. As you can see, complete rubbish. If I take out the padding and change everything to double (my float_f typedef lets me do that easily), it looks like this: arg1 =3D 1.000000, arg2 =3D { 2.000000, { 3.000000, 4.000000 } } 10.0 That's the expected behavior; the all-float case should look the same. Basically with the padding, although the call works, it's using the wrong calling conventions. I think this small structure is supposed to be passed in registers. If I step over the ffi_prep_cif call to see what args were passed to it and how the sizes and alignment were set, all looks good: ffi_make_call_desc (ntotal=3D, nfixed=3D, rettype=3D0x7ffff7f97780, argtypes=3D, name_in=3D) at ffi.c:4831 4831 if (ffis !=3D FFI_OK) (gdb) p args[0] $5 =3D (ffi_type *) 0x758c80 (gdb) p args[1] $6 =3D (ffi_type *) 0xc38220 (gdb) p (*args[1]) $7 =3D {size =3D 12, alignment =3D 4, type =3D 13, elements =3D 0xc38240} (gdb) p (*args[1]).elements[0] $8 =3D (struct _ffi_type *) 0x758c80 (gdb) p (*args[1]).elements[1] $9 =3D (struct _ffi_type *) 0xb92160 (gdb) p (*(*args[1]).elements[1]) $10 =3D {size =3D 8, alignment =3D 4, type =3D 13, elements =3D 0xb92180} (gdb) p (*(*args[1]).elements[1]).elements[0] $11 =3D (struct _ffi_type *) 0x758c80 (gdb) p (*(*args[1]).elements[1]).elements[1] $12 =3D (struct _ffi_type *) 0x758c80 (gdb) p (*(*args[1]).elements[1]).elements[2] $13 =3D (struct _ffi_type *) 0x0 (gdb) p (*args[1]).elements[2] $14 =3D (struct _ffi_type *) 0x0 Both elements arrays have two elements and a null terminator. Two floats at the leaves, and a float + struct at the first level. --0__=8FBB0C63DF9F42758f9e8a93df938690918c8FBB0C63DF9F4275 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=8FBB0C63DF9F42758f9e8a93df938690@ibm.com> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=8FBB0C63DF9F42758f9e8a93df938690918c8FBB0C63DF9F4275--