[PATCH] D143637: StackProtector: add unwind cleanup paths for instrumentation.

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

It looks like this broke building libunwind. Building it now fails with (when building clang and lld and so on with this patch, and then building libunwind with just-built clang and lld and so on):

`ld64.lld: error: undefined symbol: __gxx_personality_v0`

I suppose this needs some flag to turn it off when building libunwind?

This is in a GN build. I didn't check if it's also broken in a cmake build as it's difficult (for me, at least) to do a build of libunwind that builds with just-build clang and lld. The GN build doesn't build libunwind with any `-fstack-protector-` or `_FORTIFY_SOURCE` things, but maybe it does something else silly that causes stack protection to fire when it shouldn't (…any ideas what this might be?). Or maybe stack protection is just enabled by default on darwin? But I don't see a `fno-stack-protector` flag in the libunwind cmake build either.

…hm, adding `"-fno-stack-protector"` to libunwind's cflags seems to unbreak the libunwind build. So I figure I'll add that in the GN build. The CMake build doesn't seem to explicitly add that, so I'm guessing libunwind is broken there too. Can you look at that?

(clang/cmake/caches/Apple-stage2.cmake globally adds `-fno-stack-protector` as far as I can tell, so the Apple bots probably don't show this if they use that cache file. But if you don't use that cache file, it's probably broken now?)

I filed https://github.com/llvm/llvm-project/issues/61501 for this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143637/new/

https://reviews.llvm.org/D143637