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:
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
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
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
Summary:
The types for the compiland's children are parsed when parsing types for a PDB compiland. Global types also need to be parsed but unfortunately PDBs do not have compiland information about each global type. So we parse them all on the first call to ParseTypes.
If a sc.function is provided then parse the types for that function. Otherwise parse the types for the overall sc.comp_unit.
The ParseTypes method can be very slow if a program has a long list of compile units containing needed modules. Debugging clang-cl with lldb will show the problem.
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44253
llvm-svn: 327473
Summary:
- Complete element type of PDBSymbolTypeArray.
- Add a test to check types of multi-dimensional array and pointers with CVR.
Reviewers: zturner, rnk, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44167
llvm-svn: 326859
Summary:
All the tests pass without hitting the situation mentioned in the FIXME, so,
per Aaron Smith's suggestion, this case will now return unconditionally.
Subscribers: sanjoy, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D43215
llvm-svn: 325188
Summary:
This is combination of following changes,
- Resolve function symbols in PDB symbol file. `lldb-test symbols` will display information about function symbols.
- Implement SymbolFilePDB::FindFunctions methods. On lldb console, searching function symbol by name and by regular expression are both available.
- Create lldb type for PDBSymbolFunc.
- Add tests to check whether functions with the same name but from different sources can be resolved correctly.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: amccarth, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42443
llvm-svn: 324707
`num_args` is unsigned integer, declared as below:
```
uint32_t num_args = arg_enum->getChildCount();
```
Comparison with the signed `arg_idx` produces a warning when compiled with
-Wsign-compare flag, this patch addresses this simple issue without affecting
any functionality.
Reviewers: davide, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42620
llvm-svn: 323645
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line information about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D42434
llvm-svn: 323255
Summary:
- Fix a null array access bug. This happens when creating the lldb type for a function that has no argument.
- Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target.
- Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin
- The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type.
- Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue.
- Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's.
- There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown.
- There is no information about scoped enumeration. The compiler type is represented as an unscoped one.
Reviewers: zturner, lldb-commits, davide, asmith
Reviewed By: zturner, asmith
Subscribers: llvm-commits, davide
Differential Revision: https://reviews.llvm.org/D41427
llvm-svn: 322995
Summary:
This commit is a combination of the following changes:
- Cache PDB's global scope (executable) in SymbolFilePDB
- Change naming of `cu` to `compiland` which is PDB specific
- Change ParseCompileUnitForSymIndex to ParseCompileUnitForUID.
Prefer using a common name `UID` instead of PDB's `System Index`
Adding one more argument `index` to this method, which is used to
specify the index of the compile unit in a cached compile unit array
- Add GetPDBCompilandByUID method to simply code
- Fix a bug in getting the source file name for a PDB compiland.
For some reason, PDBSymbolCompiland::getSourceFileName() could
return an empty name, so if that is true, we have to walk through all
source files of this compiland and determine the right source file
used to generate this compiland based on language indicated.
The previous implementation called PDBSession::findOneSourceFile
method to get its name for the compiland. This is not accurate since
the `one source file` found could be a header other than source file.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41428
llvm-svn: 322433
Summary: D41086 fixed an exception in FindTypes()/FindTypesByRegex() and caused two lldb unit test to fail. This change updates the unit tests to pass again.
Reviewers: zturner, lldb-commits, labath, clayborg, asmith
Reviewed By: asmith
Differential Revision: https://reviews.llvm.org/D41550
llvm-svn: 321511
Summary:
It was possible when searching for a symbol by regex in a pdb that an invalid regex would cause an exception on Windows. This updates the code to avoid throwing an exception.
When fixing the exception it was decided there is no reason to search for a symbol in a pdb by regex. To support this, SymbolFilePDB::FindTypes() now only searches for types by name and no longer calls FindTypesByRegEx().
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: clayborg
Differential Revision: https://reviews.llvm.org/D41086
llvm-svn: 321344
A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespace due to the
`using namespace llvm;` and `using namespace lldb_private;`. Explicitly
qualify the `Type` to resolve the ambiguity. NFC
llvm-svn: 312841
Summary:
The dependencies of our libraries (only liblldb, really) we marked as public, which caused all
their dependencies to be repeated when linking any executables to them. This is a problem because
then all the .a files could end up being linked twice, once to liblldb and once
again to to the executable linking against liblldb (lldb, lldb-mi). As it turns out,
our build actually depends on this behavior:
- on windows, lldb does not have getopt, so it pulls it from inside liblldb, even
though getopt is not a part of the exported interface of liblldb (maybe some of
the bsd variants have this problem as well)
- lldb-mi uses llvm, which again is not exported by liblldb
This change does not actually fix these problems (that is going to be a hard
one), but it does make them explicit by moving this magic from add_lldb_library
to the places the executable targets are defined. That way, I can link the
additional .a files only on targets that really need it, and the other targets
can build cleanly and make sure we don't regress further. It also fixes the
LLVM_LINK_LLVM_DYLIB build on linux.
Reviewers: zturner, beanz
Subscribers: ki.stfu, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25680
llvm-svn: 284466
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
I changed "m_is_optimized" in lldb_private::CompileUnit over to be a lldb::LazyBool so that it can be set to eLazyBoolCalculate if it needs to be parsed later. With SymbolFileDWARFDebugMap, we don't actually open the DWARF in the .o files for each compile unit until later, and we can't tell if a compile unit is optimized ahead of time. So to avoid pulling in all .o right away just so we can answer the questions of "is this compile unit optimized" we defer it until a point where we will have the compile unit parsed.
<rdar://problem/26068360>
llvm-svn: 274585
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
llvm::Error requires all errors to be handled. Simply checking the whether there was an error is
not enough, you have to actuall call handle(All)Errors, in case there was an error.
llvm-svn: 268906
This implements a PDBASTParser and corresponding logic in
SymbolFilePDB to do type lookup by name. This is just a first
pass and leaves many aspects of type lookup unimplemented, and
just focuses on laying the framework. With this patch, you should
be able to lookup basic types by name from a PDB.
Full class definitions are not completed yet, we will instead
just return a forward declaration of the class.
Differential Revision: http://reviews.llvm.org/D18848
Reviewed by: Greg Clayton
llvm-svn: 266392
Previously line table parsing code assumed that the only gaps would
occur at the end of functions. In practice this isn't true, so this
patch makes the line table parsing more robust in the face of
functions with non-contiguous byte arrangements.
llvm-svn: 263078
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
Aaron Smith