This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ABI incompatibility between libffi and LLVM-generated callees


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]