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

["Uecker, Martin" <Martin dot Uecker at med dot uni-goettingen dot de>]

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