Commit Graph

4 Commits

Author SHA1 Message Date
Greg Clayton 109f86860a Fix issues with GCC debugging. GCC emits DWARF in unique ways that LLDB wasn't handling. This fix will fix cases where classes are forward declared using DW_TAG_structure_type and then actually defined using DW_TAG_class_type. LLDB, when it finds a forward declaration, would try and find and parse the complete type. It does this by:
1 - looking up the type basename in the type index
2 - iterate through all matches and look for decl contexts (namespace/class hierarchy) that match

The issue was the decl context matching wasn't watching for DW_TAG_class_type/DW_TAG_structure_type mismatches, and it wasn't also getting the name for DIE's that didn't have a DW_AT_name, but did have a DW_AT_specification that had a name.

llvm-svn: 186347
2013-07-15 21:10:17 +00:00
Greg Clayton a9a7d9d5da <rdar://problem/13502196>
We have the tag when figuring out the fully qualified name, append a suitable name for other types of tags when no name is available.

llvm-svn: 177966
2013-03-26 01:51:59 +00:00
Greg Clayton 855958caef <rdar://problem/13502196>
Functions in "(anonymous namespace)" was causing LLDB to crash when trying to complete a type and it would also cause functions arguments to appear in wrong place in frame display when showing function arguments.

llvm-svn: 177965
2013-03-26 01:45:43 +00:00
Greg Clayton a8022fa70d <rdar://problem/11291668>
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
2012-04-24 21:22:41 +00:00