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: "Uecker, Martin" <Martin dot Uecker at med dot uni-goettingen dot de>
- To: "law at redhat dot com" <law at redhat dot com>, "jakub at redhat dot com" <jakub at redhat dot com>
- Cc: "nd at arm dot com" <nd at arm dot com>, "paulkoning at comcast dot net" <paulkoning at comcast dot net>, "Szabolcs dot Nagy at arm dot com" <Szabolcs dot Nagy at arm dot com>, "msebor at gmail dot com" <msebor at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Wilco dot Dijkstra at arm dot com" <Wilco dot Dijkstra at arm dot com>, "ebotcazou at adacore dot com" <ebotcazou at adacore dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Date: Tue, 18 Dec 2018 16:33:48 +0000
- 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> <20181218162440.GQ23305@tucnak> <email@example.com>
Am Dienstag, den 18.12.2018, 17:29 +0100 schrieb Martin Uecker:
> Am Dienstag, den 18.12.2018, 17:24 +0100 schrieb Jakub Jelinek:
> > 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.
> Yes, something like this. If the trampolines are pre-allocated, this could
> even avoid the need to clear the cache on archs where this is needed.
And if we can make the trampolines be all the same (and it somehow derived
from the IP where it has to look for the static chain), we could map the
same page of pre-allocated trampolines and not use memory on platforms
with virtual memory.