From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28178 invoked by alias); 22 Dec 2014 19:36:07 -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 28162 invoked by uid 89); 22 Dec 2014 19:36:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: swip.net Received: from mailfe01.swip.net (HELO swip.net) (212.247.154.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Dec 2014 19:36:05 +0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received: from [82.211.201.188] (account cxu-bx4-3f4@tele2.se HELO mail) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPSA id 551590620 for libffi-discuss@sourceware.org; Mon, 22 Dec 2014 20:36:00 +0100 Received-SPF: none receiver=mailfe01.swip.net; client-ip=82.211.201.188; envelope-from=u-xsnf@aetey.se Received: (qmail 32122 invoked from network); 22 Dec 2014 19:35:40 -0000 Received: from unknown (HELO aetey.se) (eh1ba719@127.0.0.1) by mail with ESMTPA; 22 Dec 2014 19:35:40 -0000 Date: Mon, 22 Dec 2014 19:36:00 -0000 From: u-xsnf@aetey.se To: libffi-discuss@sourceware.org Subject: libffi does not follow proper ABI on ia32 (?) Message-ID: <20141222193538.GW14316@example.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00285.txt.bz2 Hello, I am following the directions given on https://sourceware.org/libffi/ about submitting bug reports to the list. Below you see excerpts from a letter posted to the pcc mailing list based on a try to build libffi with pcc (the "Portable C Compiler") This looks like libffi is not following the necessary ABI. Is there any chance for this to be fixed, short of having to learn the internals of libffi and submitting a patch? Regards, Rune ----- Forwarded message ----- Date: Sun, 21 Dec 2014 18:47:01 +0100 Subject: Re: [Pcc] libffi tests segfault with pcc (cvs 20141115 on i486) To: pcc@lists.ludd.ltu.se [skipped ...] On Sat, Dec 20, 2014 at 05:40:27PM +0100, u-lxna@aetey.se wrote: > res_dbl = ((cls_struct_12byte(*)(cls_struct_12byte, cls_struct_12byte))(code))(h_dbl, j_dbl); > The relevant code generated by pcc looks like > ... > 0x8048826 : call *%eax <=== the call > 0x8048828 : add $0x18,%esp > 0x804882b : mov %eax,%esi > 0x804882d : lea -0x80(%ebp),%edi > 0x8048830 : movsl %ds:(%esi),%es:(%edi) <=== segfault > (gdb) i r > eax 0xd 13 > while with gcc (4.2.3) it is afaict > ... > 0x080487ad : call *0xec(%esp) <=== the call > 0x080487b4 : cld > 0x080487b5 : mov 0x34(%esp),%edi > 0x080487b9 : mov 0x28(%esp),%esi > 0x080487bd : mov %ebx,%ecx > 0x080487bf : rep movsl %ds:(%esi),%es:(%edi) > 0x080487c1 : pop %ebp > 0x080487c2 : pop %eax In other words pcc is relying on the contents of %eax at the return from the function call while gcc clearly ignores/overwrites that value. https://en.wikipedia.org/wiki/X86_calling_conventions says among others about "cdecl" ABI: " the caller allocates memory and passes a pointer to it as a hidden first parameter; the callee populates the memory and returns the pointer " Which makes me wonder whether libffi conforms to the above in this case, %eax on return is 13, which value is being used as the pointer by pcc and crashes the program. Gcc seems to remember where the memory area for the data to return is and does not use the pointer "expected" to be returned by the callee. Does this analysis look correct? [skipped ...] A half-hearted check seems to show that gcc actually makes the callee return the pointer even though the caller never uses it. [skipped ...] So libffi might have to be fixed to provide the pointer too but the opinion of its developers is yet to be determined. [skipped ...] ----- End forwarded message -----