Nested functions

[fxcoudert]

This may be the cause for some crashes in procedure pointers in Fortran. In any case, here is a C crasher:

$ cat a.c
void foo(void) {
  void bar(void) { ; }
  void (*pptr)(void);
  pptr = bar;
  pptr();
}

int main (void) {
  foo();
}
$ ./bin/gcc a.c -O1 && ./a.out
$ ./bin/gcc a.c -O0 && ./a.out
zsh: segmentation fault  ./a.out

[fxcoudert]

This is the cause for the only libgomp failure: libgomp.c/pr52547.c

[iains]

could you try your case with "-fno-trampolines" ?
I'm rebuilding everything at the moment.

[iains]

ah, never mind, it seems that this might only be implemented for Ada.

[apinski-cavium]

Most likely the following needs to be added (when initializing the trampoline):
#ifdef HAVE_ENABLE_EXECUTE_STACK
emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__enable_execute_stack"),
LCT_NORMAL, VOIDmode, XEXP (m_tramp, 0), Pmode);
#endif

Like what is done on i386, etc.
Once I get a build going, I will test a patch for that.

[apinski-cavium]

fixtrampolines.diff.txt
This is the start of the patch, there might need some other stuff like libgcc changes done too.

[iains]

executable stack is prohibited by the kernel - I've hacked in a temporary solution using the "ada" method, but it uses bit 1 of the address, which is non-ABI-compliant.

[iains]

current hacks:
8408ba8
3fdef6d
0246f34

Future plans:

While security policy does not allow executable stack, it does allow for dynamic code generation. This would mean that we can have allocated trampolines (either from a pool or some other way) but it also means that the usage needs to be tracked, since freeing the is no longer "automatic" on scope exit.

So one of my colleagues from embecosm is looking into the following skeleton design (we plan to publish a "GCC12 project" to do this, since it should be useful to other platforms that would prefer to avoid executable stack for security reasons) -- not ready yet tho :

• the front end(s) need to be ready to emit markers on nested structures that reflect the target’s choice of lowering

• the middle end (gcc/nested.c) needs to react to those

• in particular the new piece of work is tracking nested function scopes so that a cleanup may be added (it might be relatively simple to implement, e.g. using a gimple with_cleanup operation)
• inventing the builtin to control that cleanup
• I think that there are compiler builtins to deal with trampoline and descriptor cases, but this might need a hybrid (since we have a descriptor for a trampoline that is not on the stack - so the descriptor doesn’t completely replace the trampoline like the Adacode solution … although they do still use the trampoline builtin stuff in some way)

• the back end(s) need to deal with the allocation / generation / deallocation of the trampolines at the appropriate pass (possibly expand?)

[iains]

c0f7a8f

includes the proposed (and posted) replacement implementation which uses a heap-allocated trampoline.

[crazypill]

Thank you! Thank you! Thank you! I’ve been hoping and praying for this fix and it’s a new year miracle! I really appreciate all the work you and the community have been putting into porting gcc/gfortran to Apple M1. Without this latest fix, WSJT-X (a weak signal ham radio application used by 1000’s of hams) would crash due to nested function callback and non-executable stack. I’ve been trying to get the app running native and this was a big stumbling block for me. Now it finally decodes without crashing! Thanks again for the great work- best wishes for the New Year. alex

…

On Dec 25, 2021, at 2:09 AM, iains ***@***.***> wrote: c0f7a8f includes the proposed (and posted) replacement implementation which uses a heap-allocated trampoline. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[fxcoudert]

There are no known failures with nested functions in the new implementation. Closing this.

[Nicholaswogan]

@fxcoudert when do you expect hombrew binaries to be updated with an Apple Silicon gfortran that works with nested functions? Also thanks a million for this fix. You all are very under appreciated!

[fxcoudert]

I was aiming at the next GCC 11 minor release. Or waiting for GCC 12. Since the new scheme is incompatible with the previous (partial) implementation, and even though we always labeled support in GCC 11 as experimental, I'm a bit worried about breaking code for current users.

[Nicholaswogan]

@fxcoudert I hear GCC 12 will come out in April 2022. Will updated Apple Silicon GCC binaries be available then as well?