This is the mail archive of the
gcc-patches@gcc.gnu.org
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: <1544781926.10326.8.camel@med.uni-goettingen.de> <17025085-3d47-0b16-c9d3-fec8d1ae9f39@redhat.com> <56b1e591-4d32-672f-6a30-11a9a0b167b7@gmail.com> <1544967934.14155.1.camel@med.uni-goettingen.de> <af880225-7417-5204-87cd-f9707fde554e@redhat.com> <1545000327.30232.11.camel@med.uni-goettingen.de> <05b12e7e-b6dd-fa8d-94cb-35ec9c512950@arm.com> <1545070952.3328.5.camel@med.uni-goettingen.de> <da4263fd-9b70-7bd8-f662-e12a335dc4a7@arm.com> <5896AE4C-D296-4FAF-A809-7BACA532BBF5@comcast.net> <20181218153209.GP23305@tucnak> <81804969-da3b-80b8-98d2-beb31cd19541@redhat.com>
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
trampolines).
Best,
Martin
> 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.
>
>
> Jeff