public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: planrichi@gmail.com (Richard Plangger)
Cc: libffi-discuss@sourceware.org
Subject: Re: s390x ffi_closure_helper_SYSV
Date: Thu, 17 Dec 2015 15:30:00 -0000	[thread overview]
Message-ID: <20151217153018.CDD291513@oc7340732750.ibm.com> (raw)
In-Reply-To: <5672CF2D.2030401@gmail.com> from "Richard Plangger" at Dec 17, 2015 04:05:17 PM

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

  reply	other threads:[~2015-12-17 15:30 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 [this message]
2015-12-17 19:32   ` Richard Plangger
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=20151217153018.CDD291513@oc7340732750.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=planrichi@gmail.com \
    /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).