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/debug-info-global-ctor-dtor...

28 lines
1007 B
C++
Raw Normal View History

Initialize debug info for special cases of functions that lack declarations and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942. llvm-svn: 166676
2012-10-25 18:18:50 +08:00
// RUN: %clang_cc1 %s -g -fno-use-cxa-atexit -S -emit-llvm -o - \
// RUN: | FileCheck %s --check-prefix=CHECK-NOKEXT
// RUN: %clang_cc1 %s -g -fno-use-cxa-atexit -fapple-kext -S -emit-llvm -o - \
// RUN: | FileCheck %s --check-prefix=CHECK-KEXT
class A {
public:
A() {}
virtual ~A() {}
};
A glob;
A array[2];
void foo() {
static A stat;
}
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 12] [local] [def] [__cxx_global_var_init]
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 12] [local] [def] [__dtor_glob]
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 13] [local] [def] [__cxx_global_var_init1]
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 13] [local] [def] [__cxx_global_array_dtor]
[ms-cxxabi] Implement guard variables for static initialization Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
2013-09-11 04:14:30 +08:00
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 13] [local] [def] [__dtor_array]
Initialize debug info for special cases of functions that lack declarations and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942. llvm-svn: 166676
2012-10-25 18:18:50 +08:00
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line 16] [local] [def] [__dtor__ZZ3foovE4stat]
Revert "PR14569: Omit debug info for thunks" This reverts commit r189320. Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping these around - though it still seems like those tasks could be solved by a tool just using the symbol table. In a very small number of cases, thunks may be inlined & debug info might be able to save profilers & similar tools from misclassifying those cases as part of the caller. The extra changes here plumb through the VarDecl for various cases to CodeGenFunction - this provides better fidelity through a few APIs but generally just causes the CGF::StartFunction to fallback to using the name of the IR function as the name in the debug info. The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The two names that go missing (in favor of only emitting those names as linkage names) are names that can be demangled - emitting them only as the linkage name should encourage tools to do just that. Again, thanks to Dinesh Dwivedi for investigation/work on this issue. llvm-svn: 189421
2013-08-28 07:57:18 +08:00
// CHECK-NOKEXT: [ DW_TAG_subprogram ] [line {{.*}}] [local] [def]{{$}}
Initialize debug info for special cases of functions that lack declarations and are generated by Clang (global initializers/destructors, thunks) . Fixes PR13942. llvm-svn: 166676
2012-10-25 18:18:50 +08:00
Revert "PR14569: Omit debug info for thunks" This reverts commit r189320. Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping these around - though it still seems like those tasks could be solved by a tool just using the symbol table. In a very small number of cases, thunks may be inlined & debug info might be able to save profilers & similar tools from misclassifying those cases as part of the caller. The extra changes here plumb through the VarDecl for various cases to CodeGenFunction - this provides better fidelity through a few APIs but generally just causes the CGF::StartFunction to fallback to using the name of the IR function as the name in the debug info. The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The two names that go missing (in favor of only emitting those names as linkage names) are names that can be demangled - emitting them only as the linkage name should encourage tools to do just that. Again, thanks to Dinesh Dwivedi for investigation/work on this issue. llvm-svn: 189421
2013-08-28 07:57:18 +08:00
// CHECK-KEXT: [ DW_TAG_subprogram ] [line {{.*}}] [local] [def]{{$}}