Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
Summary:
This commit adds this alternate route only when parsing variable dies
corresponding to global or static variables. The motivation for this is that GCC
does not emit linkage names for functions and variables declared/defined in
anonymous namespaces. Having this alternate route fixes one part of
TestNamespace which fails when the test case is compiled with GCC.
An alternate route to get fully qualified names of functions whose linkage names
are missing will be added with a followup change. With that, the other failing
part of TestNamespace will also be fixed.
Test Plan: dotest.py -C gcc -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8569
llvm-svn: 233098
that all clients use them explicitly. This will hopefully
prevent any future confusion where things get cast to types
we don't expect.
<rdar://problem/15146458>
llvm-svn: 191984
Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:
[0] DW_TAG_class_type "vector<int>"
[1] DW_TAG_namespace "std"
This is currently used to track down forward declarations for things like "class a:🅱️:Foo;".
llvm-svn: 155488
Greg Clayton