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: "paulkoning at comcast dot net" <paulkoning at comcast dot net>, "law at redhat dot com" <law at redhat dot com>, "jakub at redhat dot com" <jakub at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "msebor at gmail dot com" <msebor at gmail dot com>, "nd at arm dot com" <nd at arm dot com>, "Wilco dot Dijkstra at arm dot com" <Wilco dot Dijkstra at arm dot com>, "ebotcazou at adacore dot com" <ebotcazou at adacore dot com>, "Szabolcs dot Nagy at arm dot com" <Szabolcs dot Nagy at arm dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Date: Tue, 18 Dec 2018 16:27:17 +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> <firstname.lastname@example.org> <email@example.com> <5896AE4C-D296-4FAF-A809-7BACA532BBF5@comcast.net> <20181218153209.GP23305@tucnak> <firstname.lastname@example.org>
Am Dienstag, den 18.12.2018, 09:03 -0700 schrieb Jeff Law:
> On 12/18/18 8:32 AM, Jakub Jelinek wrote:
> > On Tue, Dec 18, 2018 at 10:23:46AM -0500, Paul Koning wrote:
> > >
> > >
> > > > On Dec 17, 2018, at 2:23 PM, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
> > > >
> > > > On 17/12/2018 18:22, Uecker, Martin wrote:
> > > > > >
> > > > > > ...
> > > > >
> > > > > So a thread_local static variable for storing the static
> > > > > chain?
> > > >
> > > > something like that, but the more i think about it the
> > > > harder it seems: the call site of the nested function
> > > > may not be under control of the nested function writer,
> > > > in particular the nested function may be called on a
> > > > different thread, and extern library apis are unlikely
> > > > to provide guarantees about this, so in general if a
> > > > nested function escapes into an extern library then
> > > > this cannot be relied on, which limits my original
> > > > idea again to cases where there is no escape (which i
> > > > think is not that useful).
> > >
> > > I'm not sure I understand "escape" of a nested function pointer.
> > >
> > > Your description makes it sound like you're talking about a function being called by someone
> > > who has been given the pointer, from outside the scope of the function. That sounds like an
> > > illegal operation, exactly as it would be if you attempted to reference an automatic variable
> > > via a pointer from outside the scope of that variable.
> > >
> > > Did I misunderstand?
> > The most common case is when you pass a call to a nested function
> > to some function that has a function pointer argument, e.g. qsort.
> > This is well defined with GNU nested functions, but the function that calls
> > the callback (qsort in this case) doesn't know it is a call to a nested
> > function.
> 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
> need either linker hackery or special code to compare function pointers
> to preserve ISO C behavior.
If it has to work with existing code and without the restrictions
discussed above then you have to create a pointer to a new code address
for each nested functions. One possibility which comes to mind would be a
shadow stack which is executable (and might contain pre-allocated
> Note that if you have a nested function and take its address, then go
> out of scope of the containing function, then that function pointer is
> no longer valid -- which makes perfect sense if you think about it. THe
> trampoline was on the stack and if you go out of scope of the containing
> function, then that stack frame is invalid and you also don't have a
> suitable frame chain to pass to the nested function either.