[PATCH] [libcxxabi] Add support for building and testing the unwinder.

[Dan Albert]

>>! In D4448#6, @jroelofs wrote:
>> (non-ARM Linux won't build by design).
> 
> Why?

Because there is no support for it. It isn't actually my code that prevents it from building, but rather the check at src/Unwind/UnwindCursor.hpp:1278 which requires either _LIBUNWIND_SUPPORT_COMPACT_UNWIND, _LIBUNWIND_SUPPORT_DWARF_UNWIND, or LIBCXXABI_AM_EHABI. The config that was added with the EHABI change left the dwarf and compact defines set to 0 because neither is available yet (for Linux). I'm working on fixing this right now, but it will be a different patch.

================
Comment at: src/Unwind/CMakeLists.txt:15
@@ +14,3 @@
+
+set_source_files_properties(${LIBUNWIND_ASM_SOURCES} PROPERTIES LANGUAGE C)
+
----------------
Jon Roelofs wrote:
> I'm very 'green' when it comes to cmake, but this looks odd. Should the language be set to some ASM thing instead of C?
I had done that originally, but it didn't work when building in tree. I'm also pretty new to cmake, but I looked at compiler-rt and this is how they handle it.

================
Comment at: src/Unwind/CMakeLists.txt:29
@@ +28,3 @@
+  libunwind_ext.h
+)
+
----------------
Jon Roelofs wrote:
> Sort them?
> 
> What about:
> include/libunwind.h
> include/unwind.h
> include/mach-o/compact_unwind_encoding.h
I think I may have mistakenly added those to the cxxabi target rather than the unwinder... I'll fix that.

================
Comment at: test/lit.cfg:209
@@ -202,1 +208,3 @@
+            else:
+                link_flags += ['-lgcc_eh', '-lgcc_s']
         else:
----------------
Jon Roelofs wrote:
> This changes the order of link_flags when not using llvm_unwinder. Is that okay?
I was wondering the same thing. I'll try to find more info.

http://reviews.llvm.org/D4448