This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C


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.

brgds, H-P

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]