On 17/12/2018 18:22, Uecker, Martin wrote: > 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 see. i think that's not a common use-case. i'd expect nested function pointers to often escape (as callbacks to extern library function calls). >> 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? 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).
