@phausler, have we seen this before?

Yea this is when the library is compiled incorrectly for Windows. Normally executable stacks are allowed, however I don't think Foundation claims that anywhere in the build scripts. I guess we could add Wa,-noexecstack to the library but I am not certain if we will need to do that for all libraries or not.

Comment by Thorsten Behrens (JIRA)

This is using the Linux library, libFoundation.so. It is incorrectly (hopefully incorrectly) flagged as requiring an executable stack. "execstack -c libFoundation.so" will allow it to be used inside WSL (Bash on Ubuntu on Windows).

This will also be an issue with SELinux and Exec Shield in certain flavors of Linux.

The root cause is likely inside .S files. I'll take a look this week and see what I can find. Please see https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart for reference.

-Wa,--noexecstack would work in that case. It'd be preferred to fix the .S files directly, though, as that's closer to root cause.

Comment by Thorsten Behrens (JIRA)

One step further. Found the three files that cause this for libFoundation.so, it's the three files that I thought might be the root cause here. Also found additional files in llvm that have a similar issue. Might be worthwhile looking into.

!WX means - no GNU-stack segment found, defaulting to executable stack. That's good news, as it means it can be solved by just adding conditional to those .S files, see earlier Gentoo link.

LLVM is a good question. The !WX is present but I don't see a resulting .so or executable that has the execstack flag set. I'm not sure what the impact is, here. It's possible this can be ignored. Otherwise it'd need to be fixed upstream in LLVM.
On reflection - the LLVM object files look like snippets LLVM would combine with other code. There's likely no issue here.

I'll take a stab at libFoundation.so next.

!WX — — ./Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/CoreFoundation/String.subproj/CFCharacterSetData.S.o
!WX — — ./Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/CoreFoundation/String.subproj/CFUniCharPropertyDatabase.S.o
!WX — — ./Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/CoreFoundation/String.subproj/CFUnicodeData.S.o
RWX — — ./Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/libFoundation.so
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/chkstk.S.o
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/chkstk2.S.o
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/floatundidf.S.o
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/floatundisf.S.o
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/builtins/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/floatundixf.S.o
!WX — — ./Ninja-ReleaseAssert/llvm-linux-x86_64/tools/clang/runtime/compiler-rt-bins/lib/xray/CMakeFiles/clang_rt.xray-x86_64.dir/xray_trampoline_x86.S.o

Comment by Thorsten Behrens (JIRA)

Confirmed that adding

#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif

to the end of those three .S files in /swift-corelibs-foundation/CoreFoundation/String.subproj resolves the problem. It's portable because of the #if defined. All three files already have

NO_EXEC_STACK_DIRECTIVE

at the end. The intent is there, it's just that GNU as doesn't work that way.

The three files for reference are:
CFCharacterSetData.S
CFUniCharPropertyDatabase.S
CFUnicodeData.S

I haven't forked libFoundation, that's next so I can give you a pull request for this. Contribution guidelines say to engage in the commit mailing list as well. @phausler - can you direct me on how you'd want this suggested fix to come in?

Adding that bit of code into those files seems quite reasonable to me. Fork and put up a PR - of course we will want to make sure tests pass etc.

Comment by Thorsten Behrens (JIRA)

Pull request closed, apple/swift-corelibs-foundation#759 works but there's a better way to address this, by taking into account pull request 649.

Comment by Thorsten Behrens (JIRA)

I was puzzling over NO_EXEC_STACK_DIRECTIVE, which lives in CoreFoundation/Base.subproj/CFAsmMacros.h. It's meant to do exactly what I am doing manually here, which suggests that my code is not an awesome idea. It'd be better to find out why NO_EXEC_STACK_DIRECTIVE isn't defined as expected.

See https://github.com/apple/swift-corelibs-foundation/pull/649/files

I'll take a look and see why that doesn't work the way it was intended on Ubuntu.

Comment by Thorsten Behrens (JIRA)

@phausler New pull request apple/swift-corelibs-foundation#763 is in. It turns out you were already aware of the issue (pull 649), it's just that the fix didn't work on Ubuntu. By adding a check for __GNUC__, this builds on Ubuntu the way it was intended, without flagging for executable stack.