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: "hp at bitrange dot com" <hp at bitrange dot com>
- Cc: "nd at arm dot com" <nd at arm dot com>, "paulkoning at comcast dot net" <paulkoning at comcast dot net>, "law at redhat dot com" <law at redhat dot com>, "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>, "jakub at redhat dot com" <jakub at redhat dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Date: Fri, 21 Dec 2018 21:41:11 +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> <firstname.lastname@example.org> <alpine.BSF.email@example.com>
Am Freitag, den 21.12.2018, 16:13 -0500 schrieb Hans-Peter Nilsson:
> On Tue, 18 Dec 2018, Uecker, Martin wrote:
> > 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.
> All fine with new ideas, but consider the case where the nested
> functions are nested. All mentioned ideas seem to fail for the
> case where a caller (generating a trampoline to be called later)
> is re-entered, i.e. need to generate another trampoline. The
> same location can't be re-used. You need a sort of stack.
Yes, you need to be able to create arbitrary number of trampolines.
But this would work: One can use a second stack with pre-allocated
readonly trampolines. Everytime you would now create a trampoline on
the real stack you simply refer to an existing trampoline at the
same location on the parallel stack. And if these trampolines are
all identical, you only need a single real page which is mapped
Setting up a stack would be more complicated because you also
need to setup this parallel stack. Maybe simulating this second
stack with a global hash table which uses thread id and stack
pointer of the real stack as index is better...