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
next prev 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).