From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: rixed-ZMfTK6ahfJ9F0NgSq23LOA@public.gmane.org Newsgroups: gmane.comp.lib.ffi.general,gmane.lisp.guile.user Subject: Libffi (git master) and guile (git master) on MIPS n32 Date: Mon, 7 Feb 2011 22:41:50 +0100 Message-ID: <20110207214150.GA31804@yeeloong.happyleptic.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1297115058 20412 80.91.229.12 (7 Feb 2011 21:44:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 21:44:18 +0000 (UTC) To: loongson-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, guile-user-mXXj517/zsQ@public.gmane.org, libffi-discuss-R2MHTz/CkKAf7BdofF/totBPR1lH4CV8@public.gmane.org, green-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org Original-X-From: libffi-discuss-return-1098-gcfg-libffi-discuss=m.gmane.org-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org Mon Feb 07 22:44:10 2011 Return-path: Envelope-to: gcfg-libffi-discuss-1dZseelyfdZg9hUCZPvPmw@public.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1PmYsU-000891-69 for gcfg-libffi-discuss-1dZseelyfdZg9hUCZPvPmw@public.gmane.org; Mon, 07 Feb 2011 22:44:10 +0100 Original-Received: (qmail 10756 invoked by alias); 7 Feb 2011 21:44:08 -0000 Original-Received: (qmail 10746 invoked by uid 22791); 7 Feb 2011 21:44:07 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,TW_BF X-Spam-Check-By: sourceware.org Original-Received: from smtp5-g21.free.fr (HELO smtp5-g21.free.fr) (212.27.42.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Feb 2011 21:44:01 +0000 Original-Received: from yeeloong (unknown [82.67.194.89]) by smtp5-g21.free.fr (Postfix) with SMTP id 96707D4818A; Mon, 7 Feb 2011 22:43:51 +0100 (CET) Original-Received: by yeeloong (sSMTP sendmail emulation); Mon, 07 Feb 2011 22:41:50 +0100 Mail-Followup-To: rixed-ZMfTK6ahfJ9F0NgSq23LOA@public.gmane.org, loongson-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, guile-user-mXXj517/zsQ@public.gmane.org, libffi-discuss-R2MHTz/CkKAf7BdofF/totBPR1lH4CV8@public.gmane.org, green-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact libffi-discuss-help-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libffi-discuss-owner-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org Xref: news.gmane.org gmane.comp.lib.ffi.general:310 gmane.lisp.guile.user:8415 Archived-At: Hello! I encountered a bug running guile test-suite on MIPS n32. I think I understand enough to explain it, yet I don't really know who to blame for the bug. I tend to think that the error belongs to libffi but I'm unsure as I don't know how one is supposed to use libffi. The bug hits in this situation : guile uses libffi to call qsort from libc, which itself call a comparison function defined in guile, via the invoke_closure function of libguile that was defined as a libffi callback. The return type defined by guile for this comparison function was FFI_TYPE_SINT32 which looks correct with regard to qsort signature, and consequently invoke_closure() pokes a signed int into the pointer to the location of the return value (8 bytes were reserved for it by ffi_closure_N32, which is also consistent with the n32 ABI). Then we run into troubles : the return code of ffi_closure_N32 uses "ffi_cif->flag >> 8*2" to learn what is the return type instead of the actual ffi_cif->rtype. For mips, this ffi_cif->flag seams to be a simplified version of the full type that just gives the size and alignment requirements of the value and not its meaning. In the case at hand, the flag bits tell the return type is of kind "FFY_TYPE_INT", ie a 64 bits word, and it reads that into the return register v0 and then return to the C caller (qsort). The problem is : of these 64 bits, only the 32 lowest bits were set by guile, and the upper 32 are desperately random. The n32 ABI says that the return value is supposed to be stored in the 64 bits v0 register, with bit 32 extended onto the upper bits (sign extension from 32 to 64 bits). So, should the guile invoke_closure function be aware that the 32 bits int return value is expected to be sign extended and written as a 64 bits value? I doubt it; it's certainly libffi's job to handle this. So should it be libffi's ffi_closure_N32 that should only reads the lowest 32 bits of the return location and sign extend it into v0? But to do this it should know that the actual type stored in the 64 bits location is actually a 32 bits integer, so it should use the ffi_cif->rtype instead of the mere ffi_cif->flags, which seams to defeat the whole purpose of this flags. So how am I supposed to fix this? Someone with a previous experience with libffi on mips n32 please provide some advice!