On 11/22/2021 7:49 AM, Maxim Blinov wrote:
Hi all, apologies for forgetting to add the cover letter.
No worries. I'd already assumed this was to support aarch64 trampolines
on darwin by having them live elsewere as managed entities.
The motivation of this work is to provide (limited) support for GCC
nested function trampolines on targets that do not have an executable
stack. This code has been (roughly) tested by creating several
thousand nested functions (i.e. enough to force allocation of a new
page), making sure all the nested functions execute correctly, and
consequently returning back up and ensuring that the pages are freed
when there are no more active trampolines in them.
Right. I'm looking at this wondering if we should do something similar
for our new architecture. Avoiding executable stacks is a good thing :-)
One of the limitations of the implementation in its current state is
the inability to track longjmps. There has been some discussion about
instrumenting calls to setjmp/longjmp so that the state of trampolines
is correctly tracked and freed when necessary, however that hasn't
been worked on yet.
So in the longjmp case, we just leak trampolines, right? I'd think that
should be quite uncommon. It'd be nice to fix, but the benefits of
non-executable stacks may ultimately be enough to overcome the limitation.
The other question is why not do a scheme similar to what Ada does with
function descriptors? Is that not feasible for some reason? I realize
that hasn't been plumbed into the C/C++ compilers, but it may be another
viable option.
Jeff
