maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Demangle/ms-back-references.test

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

174 lines
8.3 KiB
Plaintext
Raw Normal View History

[MS Demangler] Properly handle function parameter back-refs. Properly demangle function parameter back-references. Previously we treated lists of function parameters and template parameters the same. There are some important differences with regards to back-references, and some less important differences regarding which characters can appear before or after the name. The important differences are that with a given type T, all instances of a function parameter list share the same global back-ref table. Specifically, if X and Y are function pointers, then there are 3 entities in the declaration X func(Y) which all affect and are affected by the master parameter back-ref table: 1) The parameter list of X's function type 2) the parameter list of func itself 3) The parameter list of Y's function type. The previous code would create a back-reference table that was local to a single parameter list, so it would not be shared across parameter lists. This was discovered when porting ms-back-references.test from clang's mangling tests. All of these tests should now pass with the new changes. In doing so, I split the function for parsing template and function parameters into two separate functions. This makes the template parameter list parsing code in particular very small and easy to understand now. Differential Revision: https://reviews.llvm.org/D49875 llvm-svn: 338075
2018-07-27 06:13:39 +08:00
; RUN: llvm-undname < %s | FileCheck %s
; CHECK-NOT: Invalid mangled name
?f1@@YAXPBD0@Z
; CHECK: void __cdecl f1(char const *, char const *)
?f2@@YAXPBDPAD@Z
; CHECK: void __cdecl f2(char const *, char *)
?f3@@YAXHPBD0@Z
; CHECK: void __cdecl f3(int, char const *, char const *)
?f4@@YAPBDPBD0@Z
; CHECK: char const * __cdecl f4(char const *, char const *)
?f5@@YAXPBDIDPBX0I@Z
; CHECK: void __cdecl f5(char const *, unsigned int, char, void const *, char const *, unsigned int)
?f6@@YAX_N0@Z
; CHECK: void __cdecl f6(bool, bool)
?f7@@YAXHPAHH0_N1PA_N@Z
; CHECK: void __cdecl f7(int, int *, int, int *, bool, bool, bool *)
?g1@@YAXUS@@@Z
; CHECK: void __cdecl g1(struct S)
?g2@@YAXUS@@0@Z
; CHECK: void __cdecl g2(struct S, struct S)
?g3@@YAXUS@@0PAU1@1@Z
; CHECK: void __cdecl g3(struct S, struct S, struct S *, struct S *)
?g4@@YAXPBDPAUS@@01@Z
; CHECK: void __cdecl g4(char const *, struct S *, char const *, struct S *)
?mbb@S@@QAEX_N0@Z
; CHECK: void __thiscall S::mbb(bool, bool)
?h1@@YAXPBD0P6AXXZ1@Z
; CHECK: void __cdecl h1(char const *, char const *, void (__cdecl *)(void), void (__cdecl *)(void))
?h2@@YAXP6AXPAX@Z0@Z
; CHECK: void __cdecl h2(void (__cdecl *)(void *), void *)
?h3@@YAP6APAHPAH0@ZP6APAH00@Z10@Z
; CHECK: int * (__cdecl * __cdecl h3(int * (__cdecl *)(int *, int *), int * (__cdecl *)(int *, int *), int *))(int *, int *)
?foo@0@YAXXZ
; CHECK: void __cdecl foo::foo(void)
[MS Demangler] Properly demangle templated operators. After we detected the presence of a template via ?$ we would proceed by only demangling a simple unqualified name. This means we would fail on templated operators (and perhaps other yet-to-be-determined things) This was discovered while doing some refactoring to store richer semantic information about the demangled types to pave the way for overhauling the way we handle backreferences. (Specifically, we need to defer recording or resolving back-references until a symbol has been completely demangled, because we need to use information that only occurs later in the mangled string to decide whether a back-reference should be recorded.) Differential Revision: https://reviews.llvm.org/D50145 llvm-svn: 338608
2018-08-02 02:32:47 +08:00
??$?HH@S@@QEAAAEAU0@H@Z
[MS Demangler] Resolve backreferences eagerly, not lazily. A while back I submitted a patch to resolve backreferences lazily, thinking this that it was not always possible to know in advance what type you were looking at until you had completed a full pass over the input, and therefore it would be impossible to resolve backreferences eagerly. This was mistaken though, and turned out to be an unrelated problem. In fact, the reverse is true. You *must* resolve backreferences eagerly. This is because certain types of nested mangled symbols do not share a backreference context with their parent symbol, and as such, if you try to resolve them lazily their backreference context will have been lost by the time you finish demangling the entire input. On the other hand, resolving them eagerly appears to always work, and enables us to port many more tests over. llvm-svn: 340126
2018-08-19 02:49:48 +08:00
; CHECK: struct S & __cdecl S::operator+<int>(int)
?foo_abbb@@YAXV?$A@V?$B@D@@V1@V1@@@@Z
; CHECK: void __cdecl foo_abbb(class A<class B<char>, class B<char>, class B<char>>)
?foo_abb@@YAXV?$A@DV?$B@D@@V1@@@@Z
; CHECK: void __cdecl foo_abb(class A<char, class B<char>, class B<char>>)
?foo_abc@@YAXV?$A@DV?$B@D@@V?$C@D@@@@@Z
; CHECK: void __cdecl foo_abc(class A<char, class B<char>, class C<char>>)
?foo_bt@@YAX_NV?$B@$$A6A_N_N@Z@@@Z
; CHECK: void __cdecl foo_bt(bool, class B<bool __cdecl(bool)>)
?foo_abbb@@YAXV?$A@V?$B@D@N@@V12@V12@@N@@@Z
; CHECK: void __cdecl foo_abbb(class N::A<class N::B<char>, class N::B<char>, class N::B<char>>)
?foo_abb@@YAXV?$A@DV?$B@D@N@@V12@@N@@@Z
; CHECK: void __cdecl foo_abb(class N::A<char, class N::B<char>, class N::B<char>>)
?foo_abc@@YAXV?$A@DV?$B@D@N@@V?$C@D@2@@N@@@Z
; CHECK: void __cdecl foo_abc(class N::A<char, class N::B<char>, class N::C<char>>)
?abc_foo@@YA?AV?$A@DV?$B@D@N@@V?$C@D@2@@N@@XZ
; CHECK: class N::A<char, class N::B<char>, class N::C<char>> __cdecl abc_foo(void)
?z_foo@@YA?AVZ@N@@V12@@Z
; CHECK: class N::Z __cdecl z_foo(class N::Z)
?b_foo@@YA?AV?$B@D@N@@V12@@Z
; CHECK: class N::B<char> __cdecl b_foo(class N::B<char>)
?d_foo@@YA?AV?$D@DD@N@@V12@@Z
; CHECK: class N::D<char, char> __cdecl d_foo(class N::D<char, char>)
?abc_foo_abc@@YA?AV?$A@DV?$B@D@N@@V?$C@D@2@@N@@V12@@Z
; CHECK: class N::A<char, class N::B<char>, class N::C<char>> __cdecl abc_foo_abc(class N::A<char, class N::B<char>, class N::C<char>>)
?foo5@@YAXV?$Y@V?$Y@V?$Y@V?$Y@VX@NA@@@NB@@@NA@@@NB@@@NA@@@Z
; CHECK: void __cdecl foo5(class NA::Y<class NB::Y<class NA::Y<class NB::Y<class NA::X>>>>)
?foo11@@YAXV?$Y@VX@NA@@@NA@@V1NB@@@Z
; CHECK: void __cdecl foo11(class NA::Y<class NA::X>, class NB::Y<class NA::X>)
?foo112@@YAXV?$Y@VX@NA@@@NA@@V?$Y@VX@NB@@@NB@@@Z
; CHECK: void __cdecl foo112(class NA::Y<class NA::X>, class NB::Y<class NB::X>)
?foo22@@YAXV?$Y@V?$Y@VX@NA@@@NB@@@NA@@V?$Y@V?$Y@VX@NA@@@NA@@@NB@@@Z
; CHECK: void __cdecl foo22(class NA::Y<class NB::Y<class NA::X>>, class NB::Y<class NA::Y<class NA::X>>)
?foo@L@PR13207@@QAEXV?$I@VA@PR13207@@@2@@Z
; CHECK: void __thiscall PR13207::L::foo(class PR13207::I<class PR13207::A>)
?foo@PR13207@@YAXV?$I@VA@PR13207@@@1@@Z
; CHECK: void __cdecl PR13207::foo(class PR13207::I<class PR13207::A>)
?foo2@PR13207@@YAXV?$I@VA@PR13207@@@1@0@Z
; CHECK: void __cdecl PR13207::foo2(class PR13207::I<class PR13207::A>, class PR13207::I<class PR13207::A>)
?bar@PR13207@@YAXV?$J@VA@PR13207@@VB@2@@1@@Z
; CHECK: void __cdecl PR13207::bar(class PR13207::J<class PR13207::A, class PR13207::B>)
?spam@PR13207@@YAXV?$K@VA@PR13207@@VB@2@VC@2@@1@@Z
; CHECK: void __cdecl PR13207::spam(class PR13207::K<class PR13207::A, class PR13207::B, class PR13207::C>)
?baz@PR13207@@YAXV?$K@DV?$F@D@PR13207@@V?$I@D@2@@1@@Z
; CHECK: void __cdecl PR13207::baz(class PR13207::K<char, class PR13207::F<char>, class PR13207::I<char>>)
?qux@PR13207@@YAXV?$K@DV?$I@D@PR13207@@V12@@1@@Z
; CHECK: void __cdecl PR13207::qux(class PR13207::K<char, class PR13207::I<char>, class PR13207::I<char>>)
?foo@NA@PR13207@@YAXV?$Y@VX@NA@PR13207@@@12@@Z
; CHECK: void __cdecl PR13207::NA::foo(class PR13207::NA::Y<class PR13207::NA::X>)
?foofoo@NA@PR13207@@YAXV?$Y@V?$Y@VX@NA@PR13207@@@NA@PR13207@@@12@@Z
; CHECK: void __cdecl PR13207::NA::foofoo(class PR13207::NA::Y<class PR13207::NA::Y<class PR13207::NA::X>>)
?foo@NB@PR13207@@YAXV?$Y@VX@NA@PR13207@@@12@@Z
; CHECK: void __cdecl PR13207::NB::foo(class PR13207::NB::Y<class PR13207::NA::X>)
?bar@NB@PR13207@@YAXV?$Y@VX@NB@PR13207@@@NA@2@@Z
; CHECK: void __cdecl PR13207::NB::bar(class PR13207::NA::Y<class PR13207::NB::X>)
?spam@NB@PR13207@@YAXV?$Y@VX@NA@PR13207@@@NA@2@@Z
; CHECK: void __cdecl PR13207::NB::spam(class PR13207::NA::Y<class PR13207::NA::X>)
?foobar@NB@PR13207@@YAXV?$Y@V?$Y@VX@NB@PR13207@@@NB@PR13207@@@NA@2@V312@@Z
; CHECK: void __cdecl PR13207::NB::foobar(class PR13207::NA::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>)
?foobarspam@NB@PR13207@@YAXV?$Y@VX@NB@PR13207@@@12@V?$Y@V?$Y@VX@NB@PR13207@@@NB@PR13207@@@NA@2@V412@@Z
; CHECK: void __cdecl PR13207::NB::foobarspam(class PR13207::NB::Y<class PR13207::NB::X>, class PR13207::NA::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>)
?foobarbaz@NB@PR13207@@YAXV?$Y@VX@NB@PR13207@@@12@V?$Y@V?$Y@VX@NB@PR13207@@@NB@PR13207@@@NA@2@V412@2@Z
; CHECK: void __cdecl PR13207::NB::foobarbaz(class PR13207::NB::Y<class PR13207::NB::X>, class PR13207::NA::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>)
?foobarbazqux@NB@PR13207@@YAXV?$Y@VX@NB@PR13207@@@12@V?$Y@V?$Y@VX@NB@PR13207@@@NB@PR13207@@@NA@2@V412@2V?$Y@V?$Y@V?$Y@VX@NB@PR13207@@@NB@PR13207@@@NB@PR13207@@@52@@Z
; CHECK: void __cdecl PR13207::NB::foobarbazqux(class PR13207::NB::Y<class PR13207::NB::X>, class PR13207::NA::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>, class PR13207::NA::Y<class PR13207::NB::Y<class PR13207::NB::Y<class PR13207::NB::X>>>)
?foo@NC@PR13207@@YAXV?$Y@VX@NB@PR13207@@@12@@Z
; CHECK: void __cdecl PR13207::NC::foo(class PR13207::NC::Y<class PR13207::NB::X>)
?foobar@NC@PR13207@@YAXV?$Y@V?$Y@V?$Y@VX@NA@PR13207@@@NA@PR13207@@@NB@PR13207@@@12@@Z
; CHECK: void __cdecl PR13207::NC::foobar(class PR13207::NC::Y<class PR13207::NB::Y<class PR13207::NA::Y<class PR13207::NA::X>>>)
?fun_normal@fn_space@@YA?AURetVal@1@H@Z
; CHECK: struct fn_space::RetVal __cdecl fn_space::fun_normal(int)
??$fun_tmpl@H@fn_space@@YA?AURetVal@0@ABH@Z
; CHECK: struct fn_space::RetVal __cdecl fn_space::fun_tmpl<int>(int const &)
??$fun_tmpl_recurse@H$1??$fun_tmpl_recurse@H$1?ident@fn_space@@YA?AURetVal@2@H@Z@fn_space@@YA?AURetVal@1@H@Z@fn_space@@YA?AURetVal@0@H@Z
; CHECK: struct fn_space::RetVal __cdecl fn_space::fun_tmpl_recurse<int, &struct fn_space::RetVal __cdecl fn_space::fun_tmpl_recurse<int, &struct fn_space::RetVal __cdecl fn_space::ident(int)>(int)>(int)
??$fun_tmpl_recurse@H$1?ident@fn_space@@YA?AURetVal@2@H@Z@fn_space@@YA?AURetVal@0@H@Z
; CHECK: struct fn_space::RetVal __cdecl fn_space::fun_tmpl_recurse<int, &struct fn_space::RetVal __cdecl fn_space::ident(int)>(int)
[MS Demangler] Anonymous namespace hashes can be backreferenced. Previously we were not remembering the key values of anonymous namespaces, but we need to do this. llvm-svn: 340238
2018-08-21 07:58:58 +08:00
?AddEmitPasses@EmitAssemblyHelper@?A0x43583946@@AEAA_NAEAVPassManager@legacy@llvm@@W4BackendAction@clang@@AEAVraw_pwrite_stream@5@PEAV85@@Z
; CHECK: bool __cdecl `anonymous namespace'::EmitAssemblyHelper::AddEmitPasses(class llvm::legacy::PassManager &, enum clang::BackendAction, class llvm::raw_pwrite_stream &, class llvm::raw_pwrite_stream *)
[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 07:56:09 +08:00
??$forward@P8?$DecoderStream@$01@media@@AEXXZ@std@@YA$$QAP8?$DecoderStream@$01@media@@AEXXZAAP812@AEXXZ@Z
; CHECK: void (__thiscall media::DecoderStream<2>::*&& __cdecl std::forward<void (__thiscall media::DecoderStream<2>::*)(void)>(void (__thiscall media::DecoderStream<2>::*&)(void)))(void)