maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/mangle-ms-md5.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 lines
2.4 KiB
C++
Raw Normal View History

[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
// RUN: %clang_cc1 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck %s
[clang] Improve Microsoft mangling lit test with dblaikie's suggestions
2020-11-07 23:32:34 +08:00
// Define macros, using token pasting, to build up an identifier of any length
#define C_(P1, P2) P1##P2
#define C2(P1, P2) C_(P1, P2)
#define C4(P1, P2, P3, P4) C2(C2(P1, P2), C2(P3, P4))
#define X2(X) C2(X, X)
#define X4(X) X2(X2(X))
#define X8(X) X2(X4(X))
#define X16(X) X2(X8(X))
#define X32(X) X2(X16(X))
#define X64(X) X2(X32(X))
#define X128(X) X2(X64(X))
#define X256(X) X2(X128(X))
#define X512(X) X2(X256(X))
#define X1024(X) X2(X512(X))
#define X2048(X) X2(X1024(X))
#define X4096(X) X2(X2048(X))
#define X4095(X) \
C2(C2( \
C4(X, X2(X), X4(X), X8(X)), \
C4(X16(X), X32(X), X64(X), X128(X))), \
C4(X256(X), X512(X), X1024(X), X2048(X)))
int X4095(x);
#define Y4095 X4095(y)
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
// CHECK-DAG: @"??@bf7ea7b95f260b0b24e7f1e8fc8370ab@" = dso_local global i32 0, align 4
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
[clang] Improve Microsoft mangling lit test with dblaikie's suggestions
2020-11-07 23:32:34 +08:00
struct Y4095 {
Y4095 ();
[MS ABI] Mangle symbols names longer than 4096 characters correctly Really long symbols are hashed using MD5 and prefixed/suffixed with the usual sigils. There is an additional reason beyond the usual compatibility with MSVC, it is important to keep COFF symbols shorter than 0xFFFF because the CodeView debugging format has a maximum symbol/record size of 0xFFFF. There are some quirks worth noting: - Some mangled names reference other entities which are mangled separately. A quick example: int I; template <int *> struct S {}; S<I> s; In this case, the mangling for 's' doesn't depend directly on the mangling for 'I'. While 's' would need an MD5 hash if 'I' also needed one, the hash for 's' applied to the fully realized mangled name. In other words, the mangled name for 's' will not depend on the MD5 of the mangled name for 'I'. - Some mangled names, like the venerable CatchableType, embed the MD5 verbatim. - Finally, the complete object locator is handled as a special case. A complete object locators are mangled exactly like a VFTable except for a small deviation in the prefix sigils. However, complete object locators for hashed vftables result in a complete object locator whose name is identical to the vftable except for an additional suffix. llvm-svn: 262818
2016-03-07 16:51:17 +08:00
virtual void f();
};
[clang] Improve Microsoft mangling lit test with dblaikie's suggestions
2020-11-07 23:32:34 +08:00
Y4095::Y4095() {}
[MS] Don't escape MS C++ names with \01 It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
2018-03-17 04:36:49 +08:00
// CHECK-DAG: @"??@a6a285da2eea70dba6b578022be61d81@??_R4@" = linkonce_odr constant %rtti.CompleteObjectLocator
// CHECK-DAG: @"??@a6a285da2eea70dba6b578022be61d81@" = unnamed_addr alias
clang-cl: Fix mangling of catchable types with names longer than 4kiB The mangling used to contain the MD5 name of both the RTTI type descriptor and the name of the copy ctor in MSVC2013, but it changed to just the former in 2015. It looks like it changed back to the old mangling in VS2017 version 15.7 and onwards, including VS2019 (version 16.0). VS2017 version 15.0 still has the VS2015 mangling. Versions between 15.0 and 15.7 are't on godbolt. I found 15.4 (_MSC_VER 1911) locally and that uses the 15.0 mangling still, but I didn't find 15.5 or 15.6, so I'm not sure where exactly it changed back. Differential Revision: https://reviews.llvm.org/D62490 llvm-svn: 361959
2019-05-29 21:48:19 +08:00
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=18.0 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=HAVECTOR %s
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=19.0 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=OMITCTOR %s
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=19.10 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=OMITCTOR %s
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=19.11 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=OMITCTOR %s
// FIXME: Not known where between 19.11 and 19.14 this changed.
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=19.14 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=HAVECTOR %s
// RUN: %clang_cc1 -DTHROW -fcxx-exceptions -fms-compatibility-version=19.20 -emit-llvm -o - -triple i686-pc-win32 %s | FileCheck --check-prefix=HAVECTOR %s
#ifdef THROW
void g() {
[clang] Improve Microsoft mangling lit test with dblaikie's suggestions
2020-11-07 23:32:34 +08:00
throw Y4095();
clang-cl: Fix mangling of catchable types with names longer than 4kiB The mangling used to contain the MD5 name of both the RTTI type descriptor and the name of the copy ctor in MSVC2013, but it changed to just the former in 2015. It looks like it changed back to the old mangling in VS2017 version 15.7 and onwards, including VS2019 (version 16.0). VS2017 version 15.0 still has the VS2015 mangling. Versions between 15.0 and 15.7 are't on godbolt. I found 15.4 (_MSC_VER 1911) locally and that uses the 15.0 mangling still, but I didn't find 15.5 or 15.6, so I'm not sure where exactly it changed back. Differential Revision: https://reviews.llvm.org/D62490 llvm-svn: 361959
2019-05-29 21:48:19 +08:00
// OMITCTOR: "_CT??@c14087f0ec22b387aea7c59083f4f546@4"
// HAVECTOR: "_CT??@c14087f0ec22b387aea7c59083f4f546@??@4ef4f8979c81f9d2224b32bf327e6bdf@4"
}
#endif