https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #12 from kargls at comcast dot net --- (In reply to Iain Sandoe from comment #11) > (In reply to kargls from comment #10) > > I suppose the question then comes down to where does the > > > > .section .note.GNU-stack,"x",@progbits > > > > come from in the z-y.s save-temps file. > > There's nothing unexpected here. > > It comes from the requirements of the trampoline - which is used to call a > nested function via a function pointer. > > What (the GCC default) edition of the nested function support does is to > build a small piece of executable code on the stack that is written from a > template (but includes the runtime-variable addresses required to call the > target function). > > For some platforms use of executable stack is warned (what you see) and for > some it's forbidden (e.g. arm64 Darwin). In the case that we have a warning > we can choose to filter it or suppress it. > > If you consider that the warning should be treated as significant, then > there's an alternate implementation for the trampoline which places the > executable fragment on the heap (we can then regulate when that heap page is > writeable to be mutually exclusive with when it's executable) - which > provides a measure more of security than the blanket enable on the stack. > To use this means implementing a couple of builtin functions in libgcc and > then dealing with enabling it. I don't know exactly what would be required > for *BSD .. but it's probably not wildly different from Linux or Darwin - > and we've implemented it on both of those. Thanks for the explanation. This looks like something that would need to be coordinated with FreeBSD toolchain developers. The default linker on FreeBSD is /usr/bin/ld, which is a symlink to ld.lld. % ld.lld --version LLD 18.1.6 (FreeBSD llvmorg-18.1.6-0-g1118c2e05e67-1500000) (compatible with GNU linkers) Its manual page also shows the -z option. So, for now, users can use the option suppress the warning.
