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
Andrew Haley <aph@redhat.com> writes:
> On 02/03/2013 03:28 AM, Mark H Weaver wrote:
>> I've attached a patch to work around the LLVM bug. It has been
>> tested on Mac OS, and is confirmed to fix the problem. Comments and
>> suggestions welcome.
>
> That looks right. However, I wonder if the same bug may bite with
> unsigned types. I suppose it's unlikely, but it is theoretically
> possible.
LLVM assumes that unsigned integers will be zero-extended by the caller,
which is what this patch does. For example:
--8<---------------cut here---------------start------------->8---
#include <stdint.h>
int32_t external_callee (int8_t a, uint8_t b);
int32_t callee (int8_t a, uint8_t b)
{
return a + b;
}
int32_t caller (void)
{
return external_callee (-1, -1);
}
--8<---------------cut here---------------end--------------->8---
Clang 3.2 compiles this as follows (heavily excerpted):
--8<---------------cut here---------------start------------->8---
callee: # @callee
addl %esi, %edi
movl %edi, %eax
ret
caller: # @caller
movl $-1, %edi
movl $255, %esi
jmp external_callee # TAILCALL
--8<---------------cut here---------------end--------------->8---
When I wrote simply that LLVM assumes that integer arguments will be
sign-extended, that was based on the notion that unsigned integers have
an implicit zero sign bit, so sign-extending them is the same as
zero-extending them. Sorry if that was unclear.
Regards,
Mark