This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: ABI incompatibility between libffi and LLVM-generated callees
- From: Andrew Haley <aph at redhat dot com>
- To: Mark H Weaver <mhw at netris dot org>
- Cc: libffi-discuss at sourceware dot org
- Date: Wed, 30 Jan 2013 14:23:40 +0000
- Subject: Re: ABI incompatibility between libffi and LLVM-generated callees
- References: <87boc7jfgi.fsf@tines.lan> <5109032A.7010602@redhat.com>
On 01/30/2013 11:25 AM, Andrew Haley wrote:
> On 01/30/2013 07:30 AM, Mark H Weaver wrote:
>> Hello all,
>>
>> I'm a developer of Guile 2.0, which uses libffi, and we've received
>> multiple bug reports of test failures on OS X related to libffi. We
>> recently discovered the root cause of these failures.
>>
>> Functions compiled using LLVM for the x86_64 architecture assume that
>> callers will sign-extend integer arguments less than 64-bits that are
>> passed in registers. Indeed, both GCC and LLVM generate code that does
>> this sign-extension in callers, so it seems that their assumption is
>> reasonable.
>>
>> The only problem is that libffi does *not* sign-extend integer arguments
>> passed in registers on x86_64. Instead it zero-extends them, even if
>> they are signed. This works when calling GCC-compiled code, because GCC
>> performs the sign-extension in the callee as well as the caller, but
>> LLVM-compiled code is more strict.
>>
>> Having read section 3.2.3 ("Parameter Passing") of the SysV x86_64 ABI,
>> which is admittedly somewhat vague on this issue, it is far from clear
>> to me that the LLVM behavior is a bug.
>
> Isn't it? LLVM is supposed to be adding an int8_t and an int64_t, but
> it adds two int64_ts.
>
> I suspect that it is indeed an LLVM bug, but I've asked the psABI
> authors to comment.
It is an LLVM bug. See http://gcc.gnu.org/ml/gcc/2013-01/msg00448.html
Andrew.