From: Richard Plangger <planrichi@gmail.com>
To: libffi-discuss@sourceware.org
Subject: Re: s390x ffi_closure_helper_SYSV
Date: Thu, 17 Dec 2015 19:32:00 -0000 [thread overview]
Message-ID: <56730DB0.2080301@gmail.com> (raw)
In-Reply-To: <20151217153018.CDD291513@oc7340732750.ibm.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
>
next prev parent reply other threads:[~2015-12-17 19:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 15:05 Richard Plangger
2015-12-17 15:30 ` Ulrich Weigand
2015-12-17 19:32 ` Richard Plangger [this message]
2015-12-21 18:47 ` Ulrich Weigand
2015-12-22 17:03 ` Richard Plangger
2016-01-04 16:54 ` Richard Plangger
2015-12-18 15:09 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56730DB0.2080301@gmail.com \
--to=planrichi@gmail.com \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).