RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-20 19:42:54 +02:00
Code Issues Projects Releases Wiki Activity
10305a8da8
llvm-mirror/test/Demangle/ms-operators.test

249 lines
6.1 KiB
Plaintext
Raw Normal View History

[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
; RUN: llvm-undname < %s | FileCheck %s
; CHECK-NOT: Invalid mangled name
??0Base@@QEAA@XZ
; CHECK: __cdecl Base::Base(void)
??1Base@@UEAA@XZ
; CHECK: virtual __cdecl Base::~Base(void)
??2@YAPEAX_K@Z
; CHECK: void * __cdecl operator new(unsigned __int64)
??3@YAXPEAX_K@Z
; CHECK: void __cdecl operator delete(void *, unsigned __int64)
??4Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator=(int)
??6Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator<<(int)
??5Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator>>(int)
??7Base@@QEAAHXZ
; CHECK: int __cdecl Base::operator!(void)
??8Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator==(int)
??9Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator!=(int)
??ABase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator[](int)
??BBase@@QEAAHXZ
; CHECK: __cdecl Base::operator int(void)
??CBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator->(void)
??DBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator*(void)
??EBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator++(void)
??EBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator++(int)
??FBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator--(void)
??FBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator--(int)
??GBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator-(int)
??HBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator+(int)
??IBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator&(int)
??JBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator->*(int)
??KBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator/(int)
??LBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator%(int)
??MBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator<(int)
??NBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator<=(int)
??OBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator>(int)
??PBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator>=(int)
??QBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator,(int)
??RBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator()(void)
??SBase@@QEAAHXZ
; CHECK: int __cdecl Base::operator~(void)
??TBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator^(int)
??UBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator|(int)
??VBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator&&(int)
??WBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator||(int)
??XBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator*=(int)
??YBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator+=(int)
??ZBase@@QEAAHH@Z
; CHECK: int __cdecl Base::operator-=(int)
??_0Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator/=(int)
??_1Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator%=(int)
??_2Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator>>=(int)
??_3Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator<<=(int)
??_4Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator&=(int)
??_5Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator|=(int)
??_6Base@@QEAAHH@Z
; CHECK: int __cdecl Base::operator^=(int)
??_7Base@@6B@
; CHECK: const Base::`vftable'
[MS Demangler] Fix a few more edge cases. I found these by running llvm-undname over a couple hundred megabytes of object files generated as part of building chromium. The issues fixed in this patch are: 1) decltype-auto return types. 2) Indirect vtables (e.g. const A::`vftable'{for `B'}) 3) Pointers, references, and rvalue-references to member pointers. I have exactly one remaining symbol out of a few hundred MB of object files that produces a name we can't demangle, and it's related to back-referencing. llvm-svn: 340341
2018-08-21 23:23:49 +02:00
??_7A@B@@6BC@D@@@
; CHECK: const B::A::`vftable'{for `D::C'}
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??_8Middle2@@7B@
; CHECK: const Middle2::`vbtable'
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_9Base@@$B7AA
; CHECK: [thunk]: __cdecl Base::`vcall'{8, {flat}}
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_B?1??getS@@YAAAUS@@XZ@51
; CHECK: `struct S & __cdecl getS(void)'::`2'::`local static guard'{2}
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??_C@_02PCEFGMJL@hi?$AA@
[MS demangler] Use a slightly shorter unmangling for mangled strings. Before: const wchar_t * {L"%"} Now: L"%" See also PR39593. Differential Revision: https://reviews.llvm.org/D54294 llvm-svn: 346544
2018-11-09 20:28:50 +01:00
; CHECK: "hi"
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??_DDiamond@@QEAAXXZ
; CHECK: void __cdecl Diamond::`vbase dtor'(void)
??_EBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`vector deleting dtor'(unsigned int)
[MS Demangler] Fix several crashes and demangling bugs. These bugs were found by writing a Python script which spidered the entire Chromium build directory tree demangling every symbol in every object file. At the start, the tool printed: Processed 27443 object files. 2926377/2936108 symbols successfully demangled (99.6686%) 9731 symbols could not be demangled (0.3314%) 14589 files crashed while demangling (53.1611%) After this patch, it prints: Processed 27443 object files. 41295518/41295617 symbols successfully demangled (99.9998%) 99 symbols could not be demangled (0.0002%) 0 files crashed while demangling (0.0000%) The issues fixed in this patch are: * Ignore empty parameter packs. Previously we would encounter a mangling for an empty parameter pack and add a null node to the AST. Since we don't print these anyway, we now just don't add anything to the AST and ignore it entirely. This fixes some of the crashes. * Account for "incorrect" string literal demanglings. Apparently an older version of clang would not truncate mangled string literals to 32 bytes of encoded character data. The demangling code however would allocate a 32 byte buffer thinking that it would not encounter more than this, and overrun the buffer. We now demangle up to 128 bytes of data, since the buggy clang would encode up to 32 *characters* of data. * Extended support for demangling init-fini stubs. If you had something like struct Foo { static vector<string> S; }; this would generate a dynamic atexit initializer *for the variable*. We didn't handle this, but now we print something nice. This is actually an improvement over undname, which will fail to demangle this at all. * Fixed one case of static this adjustment. We weren't handling several thunk codes so we didn't recognize the mangling. These are now handled. * Fixed a back-referencing problem. Member pointer templates should have their components considered for back-referencing The remaining 99 symbols which can't be demangled are all symbols which are compiler-generated and undname can't demangle either. llvm-svn: 341000
2018-08-30 01:56:09 +02:00
??_EBase@@G3AEPAXI@Z
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: [thunk]: private: void * __thiscall Base::`vector deleting dtor'`adjustor{4}'(unsigned int)
[MS Demangler] Fix several crashes and demangling bugs. These bugs were found by writing a Python script which spidered the entire Chromium build directory tree demangling every symbol in every object file. At the start, the tool printed: Processed 27443 object files. 2926377/2936108 symbols successfully demangled (99.6686%) 9731 symbols could not be demangled (0.3314%) 14589 files crashed while demangling (53.1611%) After this patch, it prints: Processed 27443 object files. 41295518/41295617 symbols successfully demangled (99.9998%) 99 symbols could not be demangled (0.0002%) 0 files crashed while demangling (0.0000%) The issues fixed in this patch are: * Ignore empty parameter packs. Previously we would encounter a mangling for an empty parameter pack and add a null node to the AST. Since we don't print these anyway, we now just don't add anything to the AST and ignore it entirely. This fixes some of the crashes. * Account for "incorrect" string literal demanglings. Apparently an older version of clang would not truncate mangled string literals to 32 bytes of encoded character data. The demangling code however would allocate a 32 byte buffer thinking that it would not encounter more than this, and overrun the buffer. We now demangle up to 128 bytes of data, since the buggy clang would encode up to 32 *characters* of data. * Extended support for demangling init-fini stubs. If you had something like struct Foo { static vector<string> S; }; this would generate a dynamic atexit initializer *for the variable*. We didn't handle this, but now we print something nice. This is actually an improvement over undname, which will fail to demangle this at all. * Fixed one case of static this adjustment. We weren't handling several thunk codes so we didn't recognize the mangling. These are now handled. * Fixed a back-referencing problem. Member pointer templates should have their components considered for back-referencing The remaining 99 symbols which can't be demangled are all symbols which are compiler-generated and undname can't demangle either. llvm-svn: 341000
2018-08-30 01:56:09 +02:00
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??_F?$SomeTemplate@H@@QAEXXZ
; CHECK: void __thiscall SomeTemplate<int>::`default ctor closure'(void)
??_GBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`scalar deleting dtor'(unsigned int)
??_H@YAXPEAX_K1P6APEAX0@Z@Z
; CHECK: void __cdecl `vector ctor iterator'(void *, unsigned __int64, unsigned __int64, void * (__cdecl *)(void *))
??_I@YAXPEAX_K1P6AX0@Z@Z
; CHECK: void __cdecl `vector dtor iterator'(void *, unsigned __int64, unsigned __int64, void (__cdecl *)(void *))
??_JBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`vector vbase ctor iterator'(unsigned int)
??_KBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`virtual displacement map'(unsigned int)
??_LBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`eh vector ctor iterator'(unsigned int)
??_MBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`eh vector dtor iterator'(unsigned int)
??_NBase@@UEAAPEAXI@Z
; CHECK: virtual void * __cdecl Base::`eh vector vbase ctor iterator'(unsigned int)
??_O?$SomeTemplate@H@@QAEXXZ
; CHECK: void __thiscall SomeTemplate<int>::`copy ctor closure'(void)
??_SBase@@6B@
; CHECK: const Base::`local vftable'
??_TDerived@@QEAAXXZ
; CHECK: void __cdecl Derived::`local vftable ctor closure'(void)
??_U@YAPEAX_KAEAVklass@@@Z
; CHECK: void * __cdecl operator new[](unsigned __int64, class klass &)
??_V@YAXPEAXAEAVklass@@@Z
; CHECK: void __cdecl operator delete[](void *, class klass &)
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_R0?AUBase@@@8
; CHECK: struct Base `RTTI Type Descriptor'
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
llvm-undname: Add support for demangling typeinfo names typeinfo names aren't symbols but string constant contents stored in compiler-generated typeinfo objects, but llvm-cxxfilt can demangle these for Itanium names. In the MSVC ABI, these are just a '.' followed by a mangled type -- this means they don't start with '?' like all MS-mangled symbols do. Differential Revision: https://reviews.llvm.org/D67851 llvm-svn: 372602
2019-09-23 15:13:37 +02:00
.?AUBase@@
; CHECK: struct Base `RTTI Type Descriptor Name'
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_R1A@?0A@EA@Base@@8
; CHECK: Base::`RTTI Base Class Descriptor at (0, -1, 0, 64)'
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_R2Base@@8
; CHECK: Base::`RTTI Base Class Array'
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
[MS Demangler] Demangle all remaining types of operators. This demangles all remaining special operators including thunks, RTTI Descriptors, and local static guard variables. llvm-svn: 340083
2018-08-17 23:18:05 +02:00
??_R3Base@@8
; CHECK: Base::`RTTI Class Hierarchy Descriptor'
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??_R4Base@@6B@
; CHECK: const Base::`RTTI Complete Object Locator'
llvm-undname: Add test coverage for demangleInitFiniStub() llvm-svn: 362536
2019-06-04 20:06:28 +02:00
; Generated for `int Foo = f(4);` at global scope.
[MS Demangler] Demangle special operator 'dynamic initializer'. This is encoded as __E and should print something like "dynamic initializer for 'Foo'(void)" This also adds support for dynamic atexit destructor, which is basically identical but encoded as __F with slightly different description. llvm-svn: 340239
2018-08-21 01:59:21 +02:00
??__EFoo@@YAXXZ
[MS Demangler] Re-write the Microsoft demangler. This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
2018-08-27 05:48:03 +02:00
; CHECK: void __cdecl `dynamic initializer for 'Foo''(void)
[MS Demangler] Demangle special operator 'dynamic initializer'. This is encoded as __E and should print something like "dynamic initializer for 'Foo'(void)" This also adds support for dynamic atexit destructor, which is basically identical but encoded as __F with slightly different description. llvm-svn: 340239
2018-08-21 01:59:21 +02:00
llvm-undname: Add test coverage for demangleInitFiniStub() llvm-svn: 362536
2019-06-04 20:06:28 +02:00
; Generated for
; class C { static int i; };
; int C::i = f(5);
??__E?i@C@@0HA@@YAXXZ
; CHECK: void __cdecl `dynamic initializer for `private: static int C::i''(void)
[MS Demangler] Demangle special operator 'dynamic initializer'. This is encoded as __E and should print something like "dynamic initializer for 'Foo'(void)" This also adds support for dynamic atexit destructor, which is basically identical but encoded as __F with slightly different description. llvm-svn: 340239
2018-08-21 01:59:21 +02:00
??__FFoo@@YAXXZ
[MS Demangler] Re-write the Microsoft demangler. This is a pretty large refactor / re-write of the Microsoft demangler. The previous one was a little hackish because it evolved as I was learning about all the various edge cases, exceptions, etc. It didn't have a proper AST and so there was lots of custom handling of things that should have been much more clean. Taking what was learned from that experience, it's now re-written with a completely redesigned and much more sensible AST. It's probably still not perfect, but at least it's comprehensible now to someone else who wants to come along and make some modifications or read the code. Incidentally, this fixed a couple of bugs, so I've enabled the tests which now pass. llvm-svn: 340710
2018-08-27 05:48:03 +02:00
; CHECK: void __cdecl `dynamic atexit destructor for 'Foo''(void)
[MS Demangler] Demangle special operator 'dynamic initializer'. This is encoded as __E and should print something like "dynamic initializer for 'Foo'(void)" This also adds support for dynamic atexit destructor, which is basically identical but encoded as __F with slightly different description. llvm-svn: 340239
2018-08-21 01:59:21 +02:00
[MS Demangler] Fix several crashes and demangling bugs. These bugs were found by writing a Python script which spidered the entire Chromium build directory tree demangling every symbol in every object file. At the start, the tool printed: Processed 27443 object files. 2926377/2936108 symbols successfully demangled (99.6686%) 9731 symbols could not be demangled (0.3314%) 14589 files crashed while demangling (53.1611%) After this patch, it prints: Processed 27443 object files. 41295518/41295617 symbols successfully demangled (99.9998%) 99 symbols could not be demangled (0.0002%) 0 files crashed while demangling (0.0000%) The issues fixed in this patch are: * Ignore empty parameter packs. Previously we would encounter a mangling for an empty parameter pack and add a null node to the AST. Since we don't print these anyway, we now just don't add anything to the AST and ignore it entirely. This fixes some of the crashes. * Account for "incorrect" string literal demanglings. Apparently an older version of clang would not truncate mangled string literals to 32 bytes of encoded character data. The demangling code however would allocate a 32 byte buffer thinking that it would not encounter more than this, and overrun the buffer. We now demangle up to 128 bytes of data, since the buggy clang would encode up to 32 *characters* of data. * Extended support for demangling init-fini stubs. If you had something like struct Foo { static vector<string> S; }; this would generate a dynamic atexit initializer *for the variable*. We didn't handle this, but now we print something nice. This is actually an improvement over undname, which will fail to demangle this at all. * Fixed one case of static this adjustment. We weren't handling several thunk codes so we didn't recognize the mangling. These are now handled. * Fixed a back-referencing problem. Member pointer templates should have their components considered for back-referencing The remaining 99 symbols which can't be demangled are all symbols which are compiler-generated and undname can't demangle either. llvm-svn: 341000
2018-08-30 01:56:09 +02:00
??__F_decisionToDFA@XPathLexer@@0V?$vector@VDFA@dfa@antlr4@@V?$allocator@VDFA@dfa@antlr4@@@std@@@std@@A@YAXXZ
[MS Demangler] Print public:, protected:, private: if set in FunctionClass or a variable's StorageClass. undname prints them, and the information is in the decorated name, so we probably shouldn't lose it when undecorating. I spot-checked a few of the funnier-looking outputs, and undname has the same output. Differential Revision: https://reviews.llvm.org/D54396 llvm-svn: 346791
2018-11-13 21:18:26 +01:00
; CHECK: void __cdecl `dynamic atexit destructor for `private: static class std::vector<class antlr4::dfa::DFA, class std::allocator<class antlr4::dfa::DFA>> XPathLexer::_decisionToDFA''(void)
[MS Demangler] Fix several crashes and demangling bugs. These bugs were found by writing a Python script which spidered the entire Chromium build directory tree demangling every symbol in every object file. At the start, the tool printed: Processed 27443 object files. 2926377/2936108 symbols successfully demangled (99.6686%) 9731 symbols could not be demangled (0.3314%) 14589 files crashed while demangling (53.1611%) After this patch, it prints: Processed 27443 object files. 41295518/41295617 symbols successfully demangled (99.9998%) 99 symbols could not be demangled (0.0002%) 0 files crashed while demangling (0.0000%) The issues fixed in this patch are: * Ignore empty parameter packs. Previously we would encounter a mangling for an empty parameter pack and add a null node to the AST. Since we don't print these anyway, we now just don't add anything to the AST and ignore it entirely. This fixes some of the crashes. * Account for "incorrect" string literal demanglings. Apparently an older version of clang would not truncate mangled string literals to 32 bytes of encoded character data. The demangling code however would allocate a 32 byte buffer thinking that it would not encounter more than this, and overrun the buffer. We now demangle up to 128 bytes of data, since the buggy clang would encode up to 32 *characters* of data. * Extended support for demangling init-fini stubs. If you had something like struct Foo { static vector<string> S; }; this would generate a dynamic atexit initializer *for the variable*. We didn't handle this, but now we print something nice. This is actually an improvement over undname, which will fail to demangle this at all. * Fixed one case of static this adjustment. We weren't handling several thunk codes so we didn't recognize the mangling. These are now handled. * Fixed a back-referencing problem. Member pointer templates should have their components considered for back-referencing The remaining 99 symbols which can't be demangled are all symbols which are compiler-generated and undname can't demangle either. llvm-svn: 341000
2018-08-30 01:56:09 +02:00
llvm-undname: Add support for local static thread guards llvm-svn: 361835
2019-05-28 16:54:49 +02:00
??__J?1??f@@YAAAUS@@XZ@51
; CHECK: `struct S & __cdecl f(void)'::`2'::`local static thread guard'{2}
[MS Demangler] Rework the way operators are demangled. Previously, some of the code for actually parsing mangled operator names was more like formatting code in nature, and was interspersed with the demangling code which builds the AST. This means that by the time we got to the printing code, we had lost all information about what type of operator we had, and all we were left with was a string that we just had to print. However, not all operators are actually even operators. it's basically just a catch-all mangling for "special names", and for some of the other types it helps to know when we're actually doing the printing what it is. This patch changes the way things work by introducing an OperatorInfo structure and corresponding enumeration. When we demangle we store the enumeration value and demangled components separately. This gives more flexibility during printing. In doing so, some demanglings of special names which we didn't previously support come out of this for free, so we now demangle those. A few are more complex and are better left for a followup patch though. An exhaustive test of every possible operator code is included, with the ones that don't yet work commented out. llvm-svn: 340046
2018-08-17 18:14:05 +02:00
??__K_deg@@YAHO@Z
; CHECK: int __cdecl operator ""_deg(long double)
Reference in New Issue Copy Permalink