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
