Re: s390x ffi_closure_helper_SYSV

[Richard Plangger <planrichi at gmail dot com>]

Hi Ulrich,

thx for your reply. I agree that it makes sense to return a full ffi_arg
if the integral value is smaller than the machine register.

However, I still think there is something not right with the s390
implementation. Please have a look at this program:

https://gist.github.com/planrich/3fd72767812754d9104d

The program pollutes a fairly large junk of memory below the frame
pointer and then calls back to a python function (from c).
Because the ret_buffer variable (in ffi_closure_helper_SYSV) is not
initialized properly, the returned value is not the same on s390x as it
is on e.g. x86. `make` on my laptop (x86) returns without asserting, but
it does not on s390x. PPC was recently implemented on PyPy and there we
did also not hit this issue.

Cheers,
Richard

On 12/17/2015 04:30 PM, Ulrich Weigand wrote:
> 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
>