summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/PDB
Commit message (Collapse)AuthorAgeFilesLines
...
* [SymbolFilePDB] Simplify getting the source file pathAaron Smith2018-03-202-66/+2
| | | | | | | | | | | | Summary: Replace SymbolFilePDB::GetSourceFileNameForPDBCompiland() with PDBSymbolCompiland::getSourceFileFullPath(). Reviewers: zturner, rnk, lldb-commits Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44456 llvm-svn: 327925
* [SymbolFilePDB] Remove a few null pointer checks by passing refAaron Smith2018-03-193-63/+46
| | | | | | | | | | | | Reviewers: zturner, rnk, lldb-commits Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44455 llvm-svn: 327908
* [SymbolFilePDB] Rewrite ParseTypes methodAaron Smith2018-03-141-19/+48
| | | | | | | | | | | | | | | | | | | | | 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
* [SymbolFilePDB] Keep searching until the file name is found for the pdb ↵Aaron Smith2018-03-091-2/+3
| | | | | | | | | | | | | | compiland Reviewers: zturner, rnk, lldb-commits Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44182 llvm-svn: 327162
* [SymbolFilePDB] Add missing Char16 and Char32 types in a few placesAaron Smith2018-03-071-0/+10
| | | | | | | | | | Reviewers: zturner, rnk, lldb-commits Subscribers: clayborg, llvm-commits Differential Revision: https://reviews.llvm.org/D44166 llvm-svn: 326875
* [SymbolFilePDB] Minor cleanupAaron Smith2018-03-071-22/+23
| | | | | | | | | | | | | | | | | | | Summary: - Remove unused code - Adding `break` statement conditionally - Ignore empty strings in FindTypeByName Reviewers: zturner, rnk, lldb-commits Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44165 llvm-svn: 326870
* [SymbolFilePDB] Add support for CVR pointer type qualifierAaron Smith2018-03-071-20/+44
| | | | | | | | | | | | | | | | | 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
* [SymbolFilePDB] Get line number for PDBSymbolTypeEnumAaron Smith2018-03-071-8/+12
| | | | | | | | | | | | Reviewers: zturner, lldb-commits, rnk Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44164 llvm-svn: 326858
* Supply missing break in case statement.Adrian McCarthy2018-02-141-3/+1
| | | | | | | | | | | | 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
* Fix some warnings in SymbolFilePDB.cppPavel Labath2018-02-091-7/+6
| | | | llvm-svn: 324730
* [SymbolFilePDB] Add support for function symbolsAaron Smith2018-02-093-20/+749
| | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Silence signed <-> unsigned integer comparison warningKirill Bobyrev2018-01-291-1/+1
| | | | | | | | | | | | | | | | | | `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
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-232-19/+229
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it 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
* Revert "[SymbolFilePDB] Fix null array access when parsing the type of a ↵Pavel Labath2018-01-222-229/+19
| | | | | | | | | | function without any arguments, i.e. 'int main()' and add support to test it" This reverts commit r322995, as it breaks lldb-Unit::SymbolFilePDBTests.TestTypedefs <http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715>. llvm-svn: 323102
* Make loop counter unsigned in SymbolFilePDB::GetCompileUnitIndexRaphael Isemann2018-01-221-1/+1
| | | | | | | | | | | | | | Summary: This fixes a clang warning. Reviewers: zturner Reviewed By: zturner Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D42345 llvm-svn: 323075
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-192-19/+229
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it 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
* [lldb] Add support to cache a PDB's global scope and fix a bug in getting ↵Aaron Smith2018-01-133-72/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the source file name for a compiland 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
* Remove duplicate declaration from D41550; NFC Aaron Smith2017-12-281-4/+0
| | | | llvm-svn: 321514
* Update failing PDB unit tests that are searching for symbols by regexAaron Smith2017-12-281-0/+4
| | | | | | | | | | | | 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
* [lldb] Stop searching for a symbol in a pdb by regexAaron Smith2017-12-223-15/+17
| | | | | | | | | | | | | | | | | 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
* Enable more abilities in SymbolFilePDBAaron Smith2017-12-221-2/+45
| | | | | | | | | | | | | | | | Summary: 1) Finding symbols through --symfile 2) More abilities: Functions, Blocks, GlobalVariables, LocalVariables, VariableTypes Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: clayborg Differential Revision: https://reviews.llvm.org/D41092 llvm-svn: 321327
* Support scoped enums in the DWARF AST parserTamas Berghammer2017-11-071-1/+1
| | | | | | | | Subscribers: JDevlieghere Differential Revision: https://reviews.llvm.org/D39545 llvm-svn: 317563
* Plugins: fix resolution ambiguity in PDB pluginSaleem Abdulrasool2017-09-091-22/+24
| | | | | | | | | 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
* Move many other files from Core -> Utility.Zachary Turner2017-03-062-1/+2
| | | | llvm-svn: 297043
* [CMake] [4/4] Update a batch of pluginsChris Bieneman2017-01-311-4/+10
| | | | | | This is extending the updates from r293696 to more LLDB plugins. llvm-svn: 293701
* NFC: Improve comments in SymbolFilePDB.cppAdrian McCarthy2017-01-271-72/+46
| | | | | | | Mostly this just fixes bad wrapping caused by the reformat, with tiny changes sprinkled here and there. llvm-svn: 293336
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* [cmake] Make dependencies of lldb libraries private, take 2Pavel Labath2016-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-064-932/+876
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Warning about debugging optimized code was not happening without dSYMs. Now ↵Greg Clayton2016-07-051-1/+1
| | | | | | | | | | it works for DWARF in .o files on Darwin. 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
* Clean up test results on Windows.Zachary Turner2016-05-131-1/+1
| | | | | | | | | 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
* Fix assertion in SymbolFilePDBPavel Labath2016-05-091-0/+4
| | | | | | | 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
* Fix LLDB after removal of PDB_ErrorCodeZachary Turner2016-05-061-1/+1
| | | | llvm-svn: 268802
* Update for llvm change to add pdb namespace.Zachary Turner2016-05-044-43/+49
| | | | | | | r268544 moves all PDB reading code into a pdb namespace, so LLDB needs to be updated to take this into account. llvm-svn: 268545
* Initial support for reading type information from PDBs.Zachary Turner2016-04-155-12/+472
| | | | | | | | | | | | | | | | 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
* Fix SymbolFilePDB for discontiguous functions.Zachary Turner2016-03-101-29/+53
| | | | | | | | | 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
* Add support for reading line tables from PDB files.Zachary Turner2016-03-023-0/+745
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
OpenPOWER on IntegriCloud