[compiler-rt] Check __SEH__, when checking if ARM EHABI is implied

[mstorsjo]

Summary

ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, __USING_SJLJ_EXCEPTIONS__ or
__ARM_DWARF_EH__.

As Windows SEH also can be used for unwinding, check for the
__SEH__ define too, in the same way.

[mstorsjo]

@MaskRay Can you have a look at these runtimes/headers patches?

• This one, D126865 and D126866 are all the same change in different subprojects, and should be quite trivial.
• D126867 is more of the same plus some other simple fixes for libunwind.
• And finally D126868 and D126869 are a bit more complex, but have been pre-reviewed by someone else familiar with the domain.

[MaskRay]

LGTM. As mentioned in another patch, it'd be good to let the second patch adding !defined(__ARM_DWARF_EH__) && !defined(__SEH__) refer to the first patch, depending on the order you land these patches:)

Perhaps a [builtins] tag may be more specific.

compiler-rt/lib/builtins/gcc_personality_v0.c

if (encoding & DW_EH_PE_indirect) {
     result = *((const uintptr_t *)result);
   }
 
   *data = p;
   return result;
 }
 
 #if defined(__arm__) && !defined(__USING_SJLJ_EXCEPTIONS__) &&                 \
-    !defined(__ARM_DWARF_EH__)
+    !defined(__ARM_DWARF_EH__) && !defined(__SEH__)
 #define USING_ARM_EHABI 1
 _Unwind_Reason_Code __gnu_unwind_frame(struct _Unwind_Exception *,
                                        struct _Unwind_Context *);
 #endif
 
 static inline _Unwind_Reason_Code
 continueUnwind(struct _Unwind_Exception *exceptionObject,
                struct _Unwind_Context *context) {