This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Paul Koning <paulkoning at comcast dot net>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, "Uecker, Martin" <Martin dot Uecker at med dot uni-goettingen dot de>, "msebor at gmail dot com" <msebor at gmail dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>, nd <nd at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "ebotcazou at adacore dot com" <ebotcazou at adacore dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Tue, 18 Dec 2018 17:24:40 +0100
- Subject: Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <5896AE4C-D296-4FAF-A809-7BACA532BBF5@comcast.net> <20181218153209.GP23305@tucnak> <firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Dec 18, 2018 at 09:03:41AM -0700, Jeff Law wrote:
> Right. This is the classic example and highlights the ABI concerns. If
> we use the low bit to distinguish between a normal function pointer and
> a pointer to a descriptor and qsort doesn't know about it, then we lose.
> One way around this is to make *all* function pointers be some kind of
> descriptor and route all indirect calls through a resolver. THen you
Either way, you are creating a new ABI for calling functions through
function pointers. Because of how rarely GNU C nested functions are used
these days, if we want to do anything I'd think it might be better to use
trampolines, just don't place them on the stack, say have a mmaped page of
trampolines perhaps with some pointer encryption to where they jump to, so
it isn't a way to circumvent non-executable stack, and have some register
and unregister function you'd call to get or release the trampoline.
If more trampolines are needed than currently available, the library could
just mmap another such page. A problem is how it should interact with
longjmp or similar APIs, because then we could leak some trampolines (no
"destructor" for the trampoline would be called. The leaking could be
handled e.g. through remembering the thread and frame pointer for which it
has been allocated and if you ask for a new trampoline with a frame pointer
above the already allocated one, release those entries or reuse them,
instead of allocating a new one. And somehow deal with thread exit.