r319297 - Toolchain: Normalize dwarf, sjlj and seh eh

[Martin Storsjö via cfe-commits]

On Wed, 29 Nov 2017, Martin Storsjö via cfe-commits wrote:

> On Wed, 29 Nov 2017, Reid Kleckner wrote:
>
>> On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö <martin at martin.st> wrote:
>>       On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
>>             Thanks for letting me know Reid.
>>             I’ll in work and won’t be able to access the repo
>>             until lunch time. (~3
>>             hours)
>>             Feel free to revert if it is not trivial.
>>
>>             The easy fix might be to change to == x86_64 from !=
>>             x86 For is Windows in
>>             the default toolchain. That should restore the old
>>             behavior.
>> 
>>
>>       My suggestion would be to just return None for all architectures
>>       for the default windows (msvc) case. We didn't use to set any
>>       defines to indicate EH mode there before anyway, so setting it
>>       to None should make things behave just as before, right?
>> 
>> 
>> I did this slightly differently in r319363, but maybe that's silly. My
>> reasoning was that `clang -cc1 -fseh-exceptions -fexceptions` in the MSVC
>> environment should still use __CxxFrameHandler3. -fseh-exceptions indicates
>> what format of unwind information we should use, and we're still using the
>> normal SEH .xdata opcodes.
>
> No, I think this change makes sense - I was just about to write a comment 
> pointing out this spot in the code but was waiting for a compile to finish 
> before posting.
>
>> Alternatively, you could view -fseh-exceptions, -fdwarf-exceptions, and
>> -fsjlj-exceptions as choices of EH personality function,
>
> No, I don't think that'd make sense

FWIW, another reason I don't think that makes sense, is that making a 
GNU_CPlusPlus_SEH + MSVC combination probably would require quite a bit 
more changes as well.

When I tested the same in a build with assertions enabled, I didn't get 
the references to _Unwind_Resume as you did, but the compilation failed on 
some internal assertion. So making GNU_CPlusPlus_SEH usable with the 
microsoft C++ ABI would probably require a significant amount of more 
work, for very little value.

// Martin