public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Richard Henderson <rth@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,
	 libffi-discuss <libffi-discuss@sourceware.org>
Subject: Re: documentation patch, oddities, and proposals
Date: Tue, 10 Nov 2015 23:36:00 -0000	[thread overview]
Message-ID: <87si4dctqh.fsf@tromey.com> (raw)
In-Reply-To: <5639B430.2010807@redhat.com> (Richard Henderson's message of	"Wed, 4 Nov 2015 08:30:56 +0100")

I sent my documentation patch as a PR.

[...]
rth> Indeed.  I've thought about ways to fix this in the past, and the best
rth> I can think of imply an api+abi change.

rth> Basically, stop exporting all of the ffi_type_foo variables (which
rth> themselves imply nasty abi compatibility problems, due to the COPY
rth> relocs they require).

rth> Instead, have a function call taking an enumeration for the basic
rth> types, as well as the abi enum.  Which means that ppc can have two
rth> separate structures for its longdouble, which means that both can be
rth> read-only.

Ok, following up on this, here's my wish-list if an ABI break is
possible.

* Require each ABI to have a string name and provide a way to look up
  ABI by name.

  This would let generic FFI wrappers expose ABIs to their callers
  without undue difficulty.  This would be handy at least for Lisp
  bindings; and it seems reasonably lightweight.

  Also, document all ABIs -- not really an ABI problem, but worth
  pointing out.

  I suppose this could be added without breaking ABI.

* As you said, get rid of ffi_type_* globals, replace with per-ABI calls
  using the FFI_TYPE_* constants.

* Require a separate type-prep stage.  For struct types allow an out
  parameter that would fill in field offsets.  Requiring the separate
  call would make it possible for all the calls taking an ffi_type to be
  const-correct.

* Add FFI_TYPE_UNION and FFI_TYPE_ARRAY.

* Mark each ffi_type with an "ABI-specific" flag.  This would taint a
  type as ABI-specific.  Layout of a struct (or union or array) would
  propagate this flag from the members to the aggregate.  The idea here
  is that in most cases this just doesn't matter and this would give an
  easy way to notice when it does.  ffi_prep_cif could check this flag.


Adding bitfield support might be nice, not sure.

I don't care a whole lot about the ffi_arg thing, but if it isn't
completely crazy to fix it, it might be a good idea.

Tom

  parent reply	other threads:[~2015-11-10 23:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04  5:32 Tom Tromey
2015-11-04  5:35 ` Andrew Pinski
2015-11-04  7:31 ` Richard Henderson
2015-11-04 14:20   ` Tom Tromey
2015-11-04 14:24     ` Richard Henderson
2015-11-07 19:01   ` Tom Tromey
2015-11-09  7:39     ` Richard Henderson
2015-11-10 23:36   ` Tom Tromey [this message]
2015-11-16  4:27     ` Tom Tromey
2015-11-17  9:09       ` Richard Henderson

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=87si4dctqh.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=rth@redhat.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).