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 Montag, den 17.12.2018, 15:25 +0000 schrieb Szabolcs Nagy:
> On 16/12/2018 22:45, Uecker, Martin wrote:
> > Am Sonntag, den 16.12.2018, 09:13 -0700 schrieb Jeff Law:
> > > Ultimately using function descriptors is an ABI breaking choice and we
> > > might declare that function descriptors imply higher function
> > > alignments.  
> > 
> > Increasing the alignment is not an ABI breaking change.
> 
> increasing alignment _requirement_ is an abi breaking change.

You are right. The idea was to increase the minimum alignment
to always be compatible with code compiled with 
"-fno-trampolines" but without actually requiring the
alignment for other code as long as "-fno-trampolines"
is not given. 


> and it's not clear who would benefit from the new abi:
> 
> - it affects everything that does indirect calls (if alignment
> requirement is increased then in addition everything that has
> functions whose address may be taken), so it can easily affect
> existing handwritten asm and it definitely requires the rebuild
> of the c runtime to support this abi (i think it even requires
> asm changes there if you allow a thread or makecontext start
> function to be a nested function).
>
> - it makes indirect calls more expensive everywhere, even if
> nested functions are not used.

Yes, transition to "-fno-trampolines" by default would be a
major undertaking and the cost for
indirect calls might not
be acceptable. I was not proposing this.

> i think to fix the executable stack problem in practice, the
> new nested function mechanism should only require the rebuild
> of code that actually contains nested functions and thus have
> no abi or performance impact on code that never uses them.

My use case is to activate '-fno-trampolines' for some
project which use nested functions internally. This works
just fine with existing code because 1) no pointers to nested
functions escape 2) the default alignment on the existing
code is high enough.

This is a practical fix, but only when you are careful and
activate on a case by case. Of course, it is not a full solution
to the general problem. 


> i believe this can be achieved by some restrictions on nested
> function usage in a way that covers most practical use-cases:
> e.g. only allowing one active parent function call frame per
> thread, no recursive calls to it, the nested function must be
> invoked in the same thread as the parent using the same stack,
> etc. (then the new mechanism can be used safely if nested
> functions are known to follow the restrictions, the compiler
> may even emit code to check the constraints at runtime.)

So a thread_local static variable for storing the static
chain?

Best,
Martin