https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |fxcoudert at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-11-06
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sam James from comment #4)
> https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-
> segments
thanks Sam, that's an excellent write-up and saves us trying to replicate the
content here.
So .. to recap : the bottom line is that this is not specifically a technical
fault, it is more one of perceived (or actual) risk of executable stack w.r.t
malicious intent and the policy of dealing with that risk.
Having said this, there are ways in which we can avoid having to make (or abide
by) policy on executable stack.
1. On x86_64/aarch64 Linux (and on x86_64/arm64 Darwin) there's an alternate
trampoline implementation that uses the heap (-ftrampoline-impl=heap).
2. ISTR that Richi suggested that gfortran's code-gen could be restructured to
avoid the use of nested functions.
I'm of the opinion that it's not exactly a "bug" to fix here - more that
gfortran platform maintainers need to decide if they:
a) want to suppress this warning (either generally by adding the appropriate
flags to the gfortran specs, or specifically in individual test cases).
b) want to shift their platform to use heap-based trampolines (which might
involve implementing the support for it for any cases not listed in 1 above)
c) want to consider re-architecting the gfortran code-gen to avoid the use of
nested functions for their current purposes.
I'd say that (c) is well out of reach for GCC-15 and (b) is probably out of
reach for platforms without an implementation already, unless they start work
today ;). However, the call needs to be made by the individual platform
maintainer(s).
>From the PoV of Darwin the decision was made for us because Apple's new OSs no
longer allow executable stack - so we currently use heap trampolines. I would
be interested in the re-architecting idea but (i) have no idea how complex it
would be and (ii) in any event have no spare cycles to work on it.
