This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: Two bugs in unix64.S
- From: Dan Witte <dwitte at mozilla dot com>
- To: Armin Rigo <arigo at tunes dot org>
- Cc: libffi-discuss at sources dot redhat dot com
- Date: Thu, 14 Oct 2010 10:57:29 -0700 (PDT)
- Subject: Re: Two bugs in unix64.S
----- Original Message -----
> The main issue is that the ffi_call_unix64() function interprets its
> raddr argument differently than, say, ffi_call_win32() in win32.S. In
> ffi_call_win32() it is supposed to be a pointer to exactly as much
> memory as needed for the return type of the function, which I suppose
> is the intended semantics. However in ffi_call_unix64() we always
> writes 8 bytes into *raddr, even when the return type is declared as
> FFI_TYPE_SINT32 or FFI_TYPE_SINT8. The second, smaller, issue is that
> the assembler source code is missing "ret" at the end of the cases
> .Lst_uint16 and .Lst_uint32.
That's actually a bug in ffi_call_win32. It's a (apparently little-known) contract of the API that the return value pointer, for integral types, should be declared ffi_arg -- which is the size of the largest integral value.
ffi_call is supposed to sign- or zero-extend the return value into this size.
Patches accepted, I'm sure ;)
Regards,
Dan.