https://sourceware.org/bugzilla/show_bug.cgi?id=32671
--- Comment #7 from Aurelien Jarno <aurelien at aurel32 dot net> --- (In reply to Florian Weimer from comment #6) > (In reply to Aurelien Jarno from comment #5) > > I am not fully convince that we want to default to > > --enable-error-execstack=yes at this stage. It seems that there are cases > > where GCC generate code with nested functions, and I am not sure how much > > widespread is that, i have found at least one case. It seems that > > -ftrampoline-impl=heap is a workaround on some architectures, but I am not > > sure about the consequences. > > > See comment 2. In these cases, there will be markup, and it explicitly > requests an executable stack. The problematic cases are not that, it's > inputs that are not marked up at all. Thanks, indeed I misunderstood the option, it looks clearer after looking at the documentation. Overall I have mixed feeling about it. So far I have seen three main cases causing a missing .note.GNU-stack: - asm code missing the .note.GNU-stack. In that case I think it makes sense to error out (although some projects like onnxruntime target more than GNU systems and prefer to force -znoexecstack at link time on GNU systems rather than changing the asm code) - embedding data in the binary using "ld -r -b binary". Currently this command does not even emit a warning, I think it would make sense to just automatically add a .note.GNU-stack in that case instead of having to patch all of those commands to also pass -z noexecstack. - Use of llvm-mc. I haven't yet understood all the details, this command as a -no-exec-stack option but it is not the default. For the two first cases, defaulting to non executable stack when .note.GNU-stack is missing would just fix everything. Changing that into an error means a lot of code has to be patched. For the last case, at least with my current understanding, both options require patching code. -- You are receiving this mail because: You are on the CC list for the bug.
