Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As this doesn't seem to be used in the tree, this patch
removes the parameter entirely.
Reviewers: clayborg, jingham, labath
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere
Differential Revision: https://reviews.llvm.org/D46885
Patch by Tom Tromey <ttromey@mozilla.com>.
llvm-svn: 333639
rL145086 introduced m_die_array.shrink_to_fit() implemented by
exact_size_die_array.swap, it was before LLVM became written in C++11.
Differential revision: https://reviews.llvm.org/D47492
llvm-svn: 333636
GetUnitDIEPtrOnly() needs to return pointer to the first DIE.
But the first element of m_die_array after ExtractDIEsIfNeeded(true)
may move in memory after later ExtractDIEsIfNeeded(false).
DWARFDebugInfoEntry::collection m_die_array is std::vector,
its data may move during its expansion.
Differential revision: https://reviews.llvm.org/D46810
llvm-svn: 333437
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
Several functions were passing a list of 8 NameToDIE arguments around.
This puts those variables in a struct and passes that instead, reducing
code duplication and the possibility of error (swapping two arguments
accidentally).
llvm-svn: 333264
As suggested by Pavel Labath in D46810 DWARFUnit::GetUnitDIEOnly() returning
a pointer to m_first_die should not permit using methods like GetFirstChild().
Differential revision: https://reviews.llvm.org/D47276
llvm-svn: 333224
This new DWARFBaseDIE is going to be used for DWARFUnit::GetUnitDIEOnly() as
other DIEs are unavailable that time so the caller should not have methods
available to access them.
This patch is only a mechanical split without any use of it.
Differential revision: https://reviews.llvm.org/D47275
llvm-svn: 333222
Summary:
I think this makes sense for several reasons:
- better separation of concerns: DWARFUnit's job should be to provide a
nice interface to its users to access the unit contents.
ManualDWARFIndex can then use this interface to build an index and
provide it to its users.
- closer alignment with llvm parsers: there is no indexing equivalent in
llvm, and there probably never will be, as the index is very centered
around how lldb wants to access debug info. If we ever switch to
llvm's parser, this will allow us swap out DWARFUnit implementations
and keep indexing as-is.
- closer proximity of the indexing code to AppleDWARFIndex will make it
easier to keep the two in sync (e.g. right now the two use very
different algorithms to determine whether a DW_TAG_subroutine
represents a "method"). This is my primary motivation for making this
change now, but I am leaving this work to a separate patch.
The only interface change to DWARFUnit I needed to make was to add an
efficient way to iterate over the list of all DIEs. Adding this also
aligns us closer to the llvm parser.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47253
llvm-svn: 333178
Summary:
Implement FindGlobalVariables and ParseVariableContext methods.
Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.
This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.
Reviewers: rnk, zturner, lldb-commits
Subscribers: aprantl, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45224
llvm-svn: 333049
Summary:
This places the `if(m_using_apple_tables)` branches inside the
SymbolFileDWARF class behind an abstract DWARFIndex class. The class
currently has two implementations:
- AppleIndex, which searches using .apple_names and friends
- ManualIndex, which searches using a manually built index
Most of the methods of the class are very simple, and simply extract the
list of DIEs for the given name from the appropriate sub-table. The main
exception are the two GetFunctions overloads, which take a couple of
extra paramenters, including some callbacks. It was not possible to
split these up the same way as other methods, as here we were doing a
lot of post-processing on the results. The post-processing is similar
for the two cases, but not identical. I hope to factor these further in
separate patches.
Other interesting methods are:
- Preload(): do any preprocessing to make lookups faster (noop for
AppleIndex, forces a build of the lookup tables for ManualIndex).
- ReportInvalidDIEOffset(): Used to notify the users of an invalid index
(prints a message for AppleIndex, noop for ManualIndex).
- Dump(): dumps the index state (noop for AppleIndex, prints the lookup
tables for ManualIndex).
Reviewers: clayborg, JDevlieghere
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46889
llvm-svn: 332719
Summary:
The DataExtractors are cheap to copy so there is no reason to store them
by reference. Also, in my upcoming indexing refactor I am planning to
remove the apple tables data extractor members from the SymbolFileDWARF
class, so there will not be a DataExtractor with a suitable lifetime to
refer to.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D46888
llvm-svn: 332596
Summary:
The llvm version of the enum has the same enumerators, with stlightly
different names, so this is mostly just a search&replace exercise. One
concrete benefit of this is that we can remove the function for
converting between the two enums.
To avoid typing llvm::sys::path::Style::windows everywhere I import the
enum into the FileSpec class, so it can be referenced as
FileSpec::Style::windows.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46753
llvm-svn: 332247
Pavel Labath found this patch is incomplete and racy. I think there needs to
be some more mutexes even before considering DW_TAG_partial_unit.
This reverts commit 331229 which was: https://reviews.llvm.org/D40470
llvm-svn: 332200
This cleanup is designed to make the https://reviews.llvm.org/D32167 patch smaller and easier to read.
Cleanup in this patch:
Allow DWARFUnit subclasses to hand out the data that should be used when decoding data for a DIE. The information might be in .debug_info or could be in .debug_types. There is a new virtual function on DWARFUnit that each subclass must override:
virtual const lldb_private::DWARFDataExtractor &DWARFUnit::GetData() const;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different data to be used when decoding the DIE information.
Add a new pure virtual function to get the size of the DWARF unit header:
virtual uint32_t DWARFUnit::GetHeaderByteSize() const = 0;
This allows DWARFCompileUnit and eventually DWARFTypeUnit to hand out different offsets where the first DIE starts when decoding DIE information from the unit.
Added a new function to DWARFDataExtractor to get the size of an offset:
size_t DWARFDataExtractor::GetDWARFSizeOfOffset() const;
Removed dead dumping and parsing code in the DWARFDebugInfo class.
Inlined a bunch of calls in DWARFUnit for accessors that were just returning integer member variables.
Renamed DWARFUnit::Size() to DWARFUnit::GetHeaderByteSize() as it clearly states what it is doing and makes more sense.
Differential Revision: https://reviews.llvm.org/D46606
llvm-svn: 331892
Summary:
Before this patch the two paths were doing very different things
- the apple path searched the .apple_names section, which contained
mangled names, as well as basenames of all functions. It returned any
name it found.
- the non-accelerated path looked in the "full name" index we built
ourselves, which contained mangled as well as demangled names of all
functions (but no basenames). Then however, if it did not find a match
it did an extra search in the basename index, with some special
handling for anonymous namespaces.
This aligns the two paths by changing the non-accelerated path to return
the same results as in the apple-tables one. In pratice, this means we
will search in both the "basename", "method" and "fullname" indexes (in
the manual indexes these are separate indexes. This means the function
will return some slightly inappropriate results (e.g. bar::baz::foo when
one asks for a "full name" foo), but this can be handled by additional
filtering, independently indexing method. I've also stopped inserting
demangled names into the "fullname" index, as that is inconsistent with
the apple path.
Reviewers: clayborg, JDevlieghere
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46576
llvm-svn: 331855
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
This fixes a bug where
(lldb) target var g_ptr
would populate the global variables list with exactly one entry
because SymbolFileDWARF::ParseVariables() was invoked with a list of
DIEs pre-filtered by name, such that a subsequent call to
(lldb) fr var --show-globals
would only list that one variable, because CompileUnit::m_variables
was already initialized, fooling CompileUnit::GetVariableList().
CompileUnit::GetVariableList() grabs the *complete* list of variables
via (SymbolFileDWARF, ...)::ParseVariablesForContext and that still
calls CompileUnit::SetVariableList(variables) which acts as the
caching mechanism.
Differential Revision: https://reviews.llvm.org/D46220
llvm-svn: 331230
Multiple DW_TAG_compile_unit being indexed in a multithreaded way can request
reading of the same DW_TAG_partial_unit.
Unfortunately one cannot detect DWZ file ahead of time to disable such locking
overhead as DWARFCompileUnit::Extract does not read the first DIE which is the
only place one could find early enough if the DWARF file is using any
DW_TAG_partial_unit.
Differential revision: https://reviews.llvm.org/D40470
llvm-svn: 331229
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
Code commonly checks if the parent DIE is DW_TAG_compile_unit.
But DW_TAG_partial_unit also acts as DW_TAG_compile_unit for DWZ
as DWZ is using DW_TAG_imported_unit only at the top unit level.
Differential revision: https://reviews.llvm.org/D40469
llvm-svn: 331194
Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed.
Differential Revision: https://reviews.llvm.org/D45977
llvm-svn: 331049
The isOverload() method needs to account for situations where the two
methods being compared don't have the same number of arguments.
rdar://problem/39542960
llvm-svn: 330450
This patch by Greg Clayton drops the virtualization for DWARFPartialUnit.
The virtualization of DWARFUnit now matches more its LLVM counterpart.
DWZ patchset is going to be implementable without DWARFPartialUnit remapping.
https://reviews.llvm.org/D40474
This reverts commit 329423.
This reapplies commit r329305.
llvm-svn: 330084
The reverted commit changed DWARFUnit from https://reviews.llvm.org/D40466 and
https://reviews.llvm.org/D42892 that was prepared for DWARFPartialUnit and
made from it a superclass for DWARFTypeUnit. DWARFUnit's intention was:
DWARFUnit->DWARFSomeNameUnit->DWARFCompileUnit
DWARFUnit->DWARFSomeNameUnit->DWARFTypeUnit
DWARFUnit->DWARFPartialUnit
Discussed at: https://reviews.llvm.org/D45170
This reverts commit r329305.
llvm-svn: 329423
Many things that were in DWARFCompileUnit actually need to be in DWARFUnit. This patch moves all DWARFUnit specific things over into DWARFUnit and fixes the layering. This is in preparation for adding DWARFTypeUnit for the .debug_types patch.
Differential Revision: https://reviews.llvm.org/D45170
llvm-svn: 329305
Summary:
We would fail to resolve (and thus display the value of) any
templated type which contained a template template argument even
though we don't really use template arguments.
This patch adds minimal support for template template arguments,
but I doubt we need any more than that.
Reviewers: clayborg, jingham
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D44613
llvm-svn: 328984
When importing C++ methods into clang AST nodes from the DWARF symbol
table, preserve the DW_AT_linkage_name and use it as the linker
("asm") name for the symbol.
Concretely, this enables `expression` to call into names that use the
GNU `abi_tag` extension, and enables lldb to call into code using
std::string or std::list from recent versions of libstdc++. See
https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly
more robust than relying on the DWARF->clang->codegen pipeline to
roundtrip properly, but I'm not immediately aware of any other cases
in which it makes a difference.
Patch by Nelson Elhage!
Differential Revision: https://reviews.llvm.org/D40283
llvm-svn: 328658
Some PDB Symbols don't have line information. Use the section contributions to determine their compiland.
This is useful to determine the parent compiland for PDBSymbolTypeData, i.e. variables.
llvm-svn: 328232
Now the codebase can use the DWARFUnit superclass. It will make it later
seamlessly work also with DWARFPartialUnit for DWZ.
This patch is only a search-and-replace easily undone, nothing interesting
in it.
Differential revision: https://reviews.llvm.org/D42892
llvm-svn: 327810
DW_TAG_partial_unit for DWZ can be then presented by DWARFPartialUnit also
inherited from DWARFUnit.
Differential revision: https://reviews.llvm.org/D40466
llvm-svn: 327809
Summary:
When in a gmodules-like debugging scenario, you can have a parent decl context
that gets imported from an external AST. When this happens, we must be careful
to complete this type before adding children to it, otherwise it sometimes
results in a crash.
Reviewers: clayborg, jingham
Subscribers: aprantl, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43592
llvm-svn: 327750
