On 12/3/2021 12:53 AM, Iain Sandoe wrote:
On 3 Dec 2021, at 03:12, Jeff Law <jeffreya...@gmail.com> wrote:
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.
The problem is that it breaks ABI ;)
It was worth asking :-)
[in a function ptr] we need an address bit to test to determine if we are
handling a case which has the descriptor, or if we have a regular indirect call.
Unfortunately, although aarch64 aligns functions to 4 bytes, the two lower bits
are reserved by Arm and therefore we’d have to force function alignment to
8bytes and that’s an ABI break (that cannot reasonably be expected to happen)
for aarch64-darwin (or any other arch that has a release in the wild, I’d
imagine).
(FWIW, This is what I’ve currently implemented on my development branch [not
for C++, since that has no nested functions]. I implemented the change for
Fortran and re-used Martin Uecker’s proposed C impl. - but I used one of the
reserved address bits [as a work-around to get people going with the port])
Good to know. I keep thinking I should revamp how our port handles
nested functions. Right now we're using the tried and true trampolines,
but we've got low bits available, so we could go with function
descriptor approach. Or we could go with trampolines in mmap'd space
approach. I just don't want to use old fashioned trampolines :-)
Here’s the thread discussing the situation when Martin proposed the change for
C.
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html
Yea, I vaguely remember the thread. ABI stability is a pain :(
jeff
