> 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 ;)
[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])
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
Iain
