I wonder whether these types could reasonably be char, char, char, char, char, char etc., instead of being many tens of kilobytes. They don't *have* to be big in order for the unpatched library to fail the test, right? In fact the unpatched library ought to fail the test even when they're all char?
@Quuxplusone Yes, the tests fail regardless of whether the padding fields exist or how large they are. I copied them from the other libcxxabi dynamic_cast* tests. I'm not really sure what they do. Considering their sizes, I'm guessing the intent was something like, "ensure that every combination of padding fields (plus internal vptrs / alignment) yields a unique sum". Adding padding fields also seems to make pointers of different types have different values. (Maybe the "nearly empty class" stuff in the Itanium C++ ABI document is relevant.)
Maybe the padding could be smaller.
At one point, the large padding caused a stack overflow on embedded targets -- it was fixed here: https://github.com/llvm-mirror/libcxxabi/commit/eca353d4849b2b1f7bca76edb40b3534433a5a26.
Hm. Well, if it's just copied from elsewhere, then sure, whatever. :) I withdraw the comment.