[libcxxabi] Fix layout of __cxa_exception for win64, fixing static assert failures

[mstorsjo]

Summary

Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined - just check _WIN64 in addition to __LP64__.

This fixes compilation after static asserts about the struct layout were added in f2a436058fcbc11291e73badb44e243f61046183.

[steven_wu]

Looks like this is an ABI change for WIN64. If that is intended then LGTM

[rjmccall]

There's a Windows-based target that uses libUnwind-based exceptions?

[mstorsjo]

In D73838#1853443, @steven_wu wrote:

Looks like this is an ABI change for WIN64. If that is intended then LGTM

I think that's ok - I don't think it's worth complicating this further to preserve compatibility with a previous binary layout which was accidental (using !LP64 layout on a platform with 64 bit pointers).

I presume this is a break for cases where an exception is thrown across libraries that have statically linked different versions of libcxxabi?

For cases where libcxxabi is linked in dynamically, all modules would be using the same copy of libcxxabi (either old or new) and it'd be consistent? I presume the __cxa_exception offsets don't end up in the calling application's binary anywhere, unless statically linked?

Is the layout of __cxa_exception supposed to match that of libgcc/libstdc++/libsupc++? Because they don't have e.g. the reference count stuck in a padding hole for 32 bit architectures.

In D73838#1853450, @rjmccall wrote:

There's a Windows-based target that uses libUnwind-based exceptions?

MinGW toolchains normally use libgcc/libstdc++, but one can build a toolchain that uses libunwind/libcxxabi/libcxx instead; I distribute such a toolchain at https://github.com/mstorsjo/llvm-mingw. But I don't really give any ABI guarantees; I've e.g. switched unwinding mechanisms (between dwarf, sjlj and SEH) before, to avoid bugs until they're fixed properly.

[rjmccall]

In D73838#1853482, @mstorsjo wrote:

In D73838#1853443, @steven_wu wrote:

Looks like this is an ABI change for WIN64. If that is intended then LGTM

I think that's ok - I don't think it's worth complicating this further to preserve compatibility with a previous binary layout which was accidental (using !LP64 layout on a platform with 64 bit pointers).

Yeah, I think it's okay to consider this a bug.

I presume this is a break for cases where an exception is thrown across libraries that have statically linked different versions of libcxxabi?

You really aren't supposed to redundantly statically link libcxxabi like that; there are things in there that need to be unique.

For cases where libcxxabi is linked in dynamically, all modules would be using the same copy of libcxxabi (either old or new) and it'd be consistent? I presume the __cxa_exception offsets don't end up in the calling application's binary anywhere, unless statically linked?

It's supposed to have a stable layout (modulo the ability to extend it with prefixes). However, I'm not aware of any direct use of its fields by the compiler.

Is the layout of __cxa_exception supposed to match that of libgcc/libstdc++/libsupc++? Because they don't have e.g. the reference count stuck in a padding hole for 32 bit architectures.

That's interesting. Most details of the layout are indeed supposed to be portable across compilers and runtimes.

In D73838#1853450, @rjmccall wrote:

There's a Windows-based target that uses libUnwind-based exceptions?

MinGW toolchains normally use libgcc/libstdc++, but one can build a toolchain that uses libunwind/libcxxabi/libcxx instead; I distribute such a toolchain at https://github.com/mstorsjo/llvm-mingw. But I don't really give any ABI guarantees; I've e.g. switched unwinding mechanisms (between dwarf, sjlj and SEH) before, to avoid bugs until they're fixed properly.

Okay.

[mstorsjo]

In D73838#1853615, @rjmccall wrote:

I presume this is a break for cases where an exception is thrown across libraries that have statically linked different versions of libcxxabi?

You really aren't supposed to redundantly statically link libcxxabi like that; there are things in there that need to be unique.

Out of curiosity - which are these? Things like typeids not being unique, or are there things with global state as well?

[rjmccall]

In D73838#1853694, @mstorsjo wrote:

In D73838#1853615, @rjmccall wrote:

I presume this is a break for cases where an exception is thrown across libraries that have statically linked different versions of libcxxabi?

You really aren't supposed to redundantly statically link libcxxabi like that; there are things in there that need to be unique.

Out of curiosity - which are these? Things like typeids not being unique, or are there things with global state as well?

typeids are the big thing, but there's global state associated with __cxa_atexit, thread-local variables, initialization guards, the terminate and unexpected handlers, and so on.

[mstorsjo]

In D73838#1853696, @rjmccall wrote:

In D73838#1853694, @mstorsjo wrote:

In D73838#1853615, @rjmccall wrote:

I presume this is a break for cases where an exception is thrown across libraries that have statically linked different versions of libcxxabi?

You really aren't supposed to redundantly statically link libcxxabi like that; there are things in there that need to be unique.

Out of curiosity - which are these? Things like typeids not being unique, or are there things with global state as well?

typeids are the big thing, but there's global state associated with __cxa_atexit, thread-local variables, initialization guards, the terminate and unexpected handlers, and so on.

Right - ok, thanks!

[steven_wu]

The only case I know which can break after ABI change is the application has its own implementations to inspecting and handling exceptions. Almost everything go through libunwind and libcxxabi so as long as they are agree on the ABI, you have most of the cases covered.

libcxxabi/src/cxa_exception.h

 static const uint64_t kOurDependentExceptionClass = 0x434C4E47432B2B01; // CLNGC++\1
 static const uint64_t get_vendor_and_language     = 0xFFFFFFFFFFFFFF00; // mask for CLNGC++
 
 _LIBCXXABI_HIDDEN uint64_t __getExceptionClass  (const _Unwind_Exception*);
 _LIBCXXABI_HIDDEN void     __setExceptionClass  (      _Unwind_Exception*, uint64_t);
 _LIBCXXABI_HIDDEN bool     __isOurExceptionClass(const _Unwind_Exception*);
 
 struct _LIBCXXABI_HIDDEN __cxa_exception {
-#if defined(__LP64__) || defined(_LIBCXXABI_ARM_EHABI)
+#if defined(__LP64__) || defined(_WIN64) || defined(_LIBCXXABI_ARM_EHABI)
     // Now _Unwind_Exception is marked with __attribute__((aligned)),
     // which implies __cxa_exception is also aligned. Insert padding
     // in the beginning of the struct, rather than before unwindHeader.
     void *reserve;
 
     // This is a new field to support C++ 0x exception_ptr.
     // For binary compatibility it is at the start of this
     // struct which is prepended to the object thrown in

 #else
     int handlerSwitchValue;
     const unsigned char *actionRecord;
     const unsigned char *languageSpecificData;
     void *catchTemp;
     void *adjustedPtr;
 #endif
 
-#if !defined(__LP64__) && !defined(_LIBCXXABI_ARM_EHABI)
+#if !defined(__LP64__) && !defined(_WIN64) && !defined(_LIBCXXABI_ARM_EHABI)
     // This is a new field to support C++ 0x exception_ptr.
     // For binary compatibility it is placed where the compiler
     // previously adding padded to 64-bit align unwindHeader.
     size_t referenceCount;
 #endif
     _Unwind_Exception unwindHeader;
 };
 
 // http://sourcery.mentor.com/archives/cxx-abi-dev/msg01924.html
 // The layout of this structure MUST match the layout of __cxa_exception, with
 // primaryException instead of referenceCount.
 struct _LIBCXXABI_HIDDEN __cxa_dependent_exception {
-#if defined(__LP64__) || defined(_LIBCXXABI_ARM_EHABI)
+#if defined(__LP64__) || defined(_WIN64) || defined(_LIBCXXABI_ARM_EHABI)
     void* reserve; // padding.
     void* primaryException;
 #endif
 
     std::type_info *exceptionType;
     void (*exceptionDestructor)(void *);
     std::unexpected_handler unexpectedHandler;
     std::terminate_handler terminateHandler;
 
     __cxa_exception *nextException;
 
     int handlerCount;
 
 #if defined(_LIBCXXABI_ARM_EHABI)
     __cxa_exception* nextPropagatingException;
     int propagationCount;
 #else
     int handlerSwitchValue;
     const unsigned char *actionRecord;
     const unsigned char *languageSpecificData;
     void * catchTemp;
     void *adjustedPtr;
 #endif
 
-#if !defined(__LP64__) && !defined(_LIBCXXABI_ARM_EHABI)
+#if !defined(__LP64__) && !defined(_WIN64) && !defined(_LIBCXXABI_ARM_EHABI)
     void* primaryException;
 #endif
     _Unwind_Exception unwindHeader;
 };
 
 // Verify the negative offsets of different fields.
 static_assert(sizeof(_Unwind_Exception) +
                       offsetof(__cxa_exception, unwindHeader) ==
                   sizeof(__cxa_exception),
               "unwindHeader has wrong negative offsets");
 static_assert(sizeof(_Unwind_Exception) +
                       offsetof(__cxa_dependent_exception, unwindHeader) ==
                   sizeof(__cxa_dependent_exception),
               "unwindHeader has wrong negative offsets");
 
 #if defined(_LIBCXXABI_ARM_EHABI)
 static_assert(offsetof(__cxa_exception, propagationCount) +
                       sizeof(_Unwind_Exception) + sizeof(void*) ==
                   sizeof(__cxa_exception),
               "propagationCount has wrong negative offset");
 static_assert(offsetof(__cxa_dependent_exception, propagationCount) +
                       sizeof(_Unwind_Exception) + sizeof(void*) ==
                   sizeof(__cxa_dependent_exception),
               "propagationCount has wrong negative offset");
-#elif defined(__LP64__)
+#elif defined(__LP64__) || defined(_WIN64)
 static_assert(offsetof(__cxa_exception, adjustedPtr) +
                       sizeof(_Unwind_Exception) + sizeof(void*) ==
                   sizeof(__cxa_exception),
               "adjustedPtr has wrong negative offset");
 static_assert(offsetof(__cxa_dependent_exception, adjustedPtr) +
                       sizeof(_Unwind_Exception) + sizeof(void*) ==
                   sizeof(__cxa_dependent_exception),
               "adjustedPtr has wrong negative offset");