I don't know the semantics of nested procedures in Fortran, and the allowed visibility of variables those procedures can access. Trampolines are used to set up pointers to stack frames, and the direction of those pointers is presumably all to older frames.
Presumably the Fortran language is carefully defined so that the lifetime of variables in "frames" is strictly LIFO, so the frames can go onto the stack, so alloc/dealloc is "free". There are lots of caveats and special cases, and small changes to the language definition may break this simple allocation model in subtle ways. Many modern programming languages allow for "escapes", which require that frames are heap allocated. I don't know what code is in the trampoline. The lifetime of the code matches the lifetime of the LIFO frames. There's not much to the code in a trampoline, so perhaps it is like the small code found in the @plt functions. Presumably the code is "simple", since that has to be generated at run time, but perhaps the code generated is a simple copy of a byte string and patch of addresses. Alternate implementations could presumably use descriptors, and the trampoline code can be the same for all use cases, but there's an additional overhead of interpreting the descriptor. Some of the gnu docs suggest there are flags to gfortran to enable descriptor mechanisms. There's some discussion of the design of trampolines for fortran here: https://flang.llvm.org/docs/InternalProcedureTrampolines.html and https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html and here https://nullprogram.com/blog/2019/11/15/ My snarky conjecture, based on my own study and technical work in language runtimes 30+ years ago, is that trampolines were used in gfortran because, well, it was "cool", hard to master, had a snazzy unique technical vocabulary ("trampoline", "funarg", "thunk", "closure", "continuation", "escape"), and Richard Stallman knew how to do this based on his experience on MIT's lisp machines in the 1970s. (I'm old and cranky, so delight in blaming everything on Stallman) On Tue, Jan 13, 2026 at 8:30 AM Tolboom, Ryan via wsjt-devel < [email protected]> wrote: > Hello Phil, > > This article may provide some context with regard to the security > implications of trampolines and executable stacks when linking objects from > different compilers. > > https://nullprogram.com/blog/2019/11/15/ > > See the authors notes regarding the rebuttal at the bottom. > > TLDR; gun binutils ld is going to leave you with an executable stack to > support trampolines by default when linking code from different compilers. > > Hardening WSJT-X is ambitious, but given the unique nature of what it does > and the esoteric attack vectors it would probably make for the coolest > Defcon talk ever! Good luck, Robert. > > 73, > > Ryan N2BP > > > On Mon, Jan 12, 2026, 9:36 PM Phil Karn via wsjt-devel < > [email protected]> wrote: > >> I know what an executable stack means and why they’re a bad idea and I’ve >> heard of trampolines but I don’t actually know what they are or why they’re >> necessary. On Mon, Jan 12, 2026 at 15: 39 Robert Henry via wsjt-devel >> <wsjt-devel@ lists. sourceforge. net> >> I know what an executable stack means and why they’re a bad idea and I’ve >> heard of trampolines but I don’t actually know what they are or why they’re >> necessary. >> >> >> On Mon, Jan 12, 2026 at 15:39 Robert Henry via wsjt-devel < >> [email protected]> wrote: >> >>> gcc/gfortran will put executable "trampoline" code on the stack as a way >>> to implement procedures passed as arguments ("funargs" in the lingo) to >>> other procedures. >>> >>> Executable stacks are a *major* security breach, and should be avoided. >>> >>> In the wsjt Fortran code base there are 2 ways to avoid this, I think. >>> >>> (1) rewrite the fortran code involving dispatch through "callback" >>> routines. I think this is doable, and the infrastructure to support this >>> style of object oriented programming could probably be removed too. >>> >>> (2) If using GNU compilers, compile everywhere with >>> -ftrampoline-impl=heap -z noexecstack which will put trampolines on the >>> heap (dynamic memory) and tell the linker to tell the operating system to >>> not make the stack executable. >>> >>> I *think* that gcc on x86/x64 is the only pair of compilers and targets >>> that still puts trampolines on the stack. ARM, MacOsX and Windows probably >>> use the heap all the time for trampolines. >>> _______________________________________________ >>> wsjt-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/wsjt-devel__;!!DLa72PTfQgg!JsU9Rz1ouui21Hr7f9pALFMIh8NVjxxRlFEoGCEpwZgjlxoU2eV_Db5zIBv9Ig9mZujPbj6JxvJFK8cz0Bq4qu7cVf8cy6a2$> >>> >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> >> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/wsjt-devel__;!!DLa72PTfQgg!JsU9Rz1ouui21Hr7f9pALFMIh8NVjxxRlFEoGCEpwZgjlxoU2eV_Db5zIBv9Ig9mZujPbj6JxvJFK8cz0Bq4qu7cVf8cy6a2$ >> > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
