This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: s390x ffi_closure_helper_SYSV
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: planrichi at gmail dot com (Richard Plangger)
- Cc: libffi-discuss at sourceware dot org
- Date: Thu, 17 Dec 2015 16:30:18 +0100 (CET)
- Subject: Re: s390x ffi_closure_helper_SYSV
- Authentication-results: sourceware.org; auth=none
Richard Plangger wrote:
> I hit an issue with libffi that was included in CPython 2.7.10.
> Here is the github issue:
>
> https://github.com/atgreen/libffi/pull/216
>
> Let me know what you think.
I think you're running into the special case with return values
that is described here in the libffi docs:
In most situations, @samp{libffi} will handle promotion according to
the ABI. However, for historical reasons, there is a special case
with return values that must be handled by your code. In particular,
for integral (not @code{struct}) types that are narrower than the
system register size, the return value will be widened by
@samp{libffi}. @samp{libffi} provides a type, @code{ffi_arg}, that
can be used as the return type. For example, if the CIF was defined
with a return type of @code{char}, @samp{libffi} will try to store a
full @code{ffi_arg} into the return value.
I.e. when a return value is described by any of the small integral
type codes, code is expected to actually return a full ffi_arg.
While this is not explicitly mentioned in the closure docs, the
code makes the assumption that this is handled likewise for closure
return values. This is also explicitly checked for in the libffi
test suite, e.g. testsuite/libffi.call/cls_sshort.c
While this is indeed somewhat surprising, I don't think we can
simply change the behavior at this point, as other existing
users may depend on current behavior.
In any case, this is a cross-platform issue (though probably
exacerbated on big-endian platforms).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com