summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
* [PDB] Improve performance of the PDB DIA pluginAleksandr Urakov2018-10-231-25/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch improves performance of `SymbolFilePDB` on huge executables in two ways: - cache names of public symbols by address. When creating variables we are trying to get a mangled name for each one, and in `GetMangledForPDBData` we are enumerating all public symbols, which takes O(n) for each variable. With the cache we can retrieve a mangled name in O(log(n)); - cache section contributions. When parsing variables for context we are enumerating all variables and check if the current one is belonging to the current compiland. So we are retrieving a compiland ID for the variable. But in `PDBSymbolData::getCompilandId` for almost every variable we are enumerating all section contributions to check if the variable is belonging to it, and get a compiland ID from the section contribution if so. It takes O(n) for each variable, but with caching it takes about O(log(n)). I've placed the cache in `SymbolFilePDB` and have created `GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId` except for the cache part. Another option is to support caching in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it seems that the last one doesn't imply such functionality, because it's a lightweight wrapper over DIA and whole its state is only a COM pointer to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only inside of `SymbolFilePDB`, so I think that it's not a bad place to do such things. With this patch `PDBSymbolData::getCompilandId` is not used at all. This bottlenecks were found with profiling. I've discovered these on a simple demo project of Unreal Engine (x86 executable ~72M, PDB ~82M). This patch doesn't change external behavior of the plugin, so I think that there's no need for additional testing (already existing tests should warn us about regress, if any). Reviewers: zturner, asmith, labath Reviewed By: asmith Subscribers: Hui, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53375 llvm-svn: 345013
* Resubmit "Add SymbolFileNativePDB plugin."Zachary Turner2018-10-121-4/+22
| | | | | | | | | | This was originally reverted due to some test failures on Linux. Those problems turned out to require several additional patches to lld and clang in order to fix, which have since been submitted. This patch is resubmitted unchanged. All tests now pass on both Linux and Windows. llvm-svn: 344409
* Revert SymbolFileNativePDB plugin.Zachary Turner2018-10-111-22/+4
| | | | | | | | | This was originally causing some test failures on non-Windows platforms, which required fixes in the compiler and linker. After those fixes, however, other tests started failing. Reverting temporarily until I can address everything. llvm-svn: 344279
* Create a SymbolFile plugin for cross-platform PDB access.Zachary Turner2018-10-101-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing SymbolFilePDB only works on Windows, as it is written against a closed-source Microsoft SDK that ships with their debugging tools. There are several reasons we want to bypass this and go straight to the bits of the PDB, but just to list a few: More room for optimization. We can't see inside the implementation of the Microsoft SDK, so we don't always know if we're doing things in the most efficient way possible. For example, setting a breakpoint on main of a big program currently takes several seconds. With the implementation here, the time is unnoticeable. We want to be able to symbolize Windows minidumps even if not on Windows. Someone should be able to debug Windows minidumps as if they were on Windows, given that no running process is necessary. This patch is a very crude first attempt at filling out some of the basic pieces. I've implemented FindFunctions, ParseCompileUnitLineTable, and ResolveSymbolContext for a limited subset of possible parameter values, which is just enough to get it to display something nice for the breakpoint location. I've added several tests exercising this functionality which are limited enough to work on all platforms but still exercise this functionality. I'll try to add as many tests of this nature as I can, but at some point we'll need a live process. For now, this plugin is enabled always on non-Windows, and by setting the environment variable LLDB_USE_NATIVE_PDB_READER=1 on Windows. Eventually, once it's at parity with the Windows implementation, we'll delete the Windows DIA-based implementation. Differential Revision: https://reviews.llvm.org/D53002 llvm-svn: 344154
* [PDB] Restore AST from PDB symbolsAleksandr Urakov2018-09-101-22/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds an implementation of retrieving of declarations and declaration contexts based on PDB symbols. PDB has different type symbols for const-qualified types, and this implementation ensures that only one declaration was created for both const and non-const types, but creates different compiler types for them. The implementation also processes the case when there are two symbols corresponding to a variable. It's possible e.g. for class static variables, they has one global symbol and one symbol belonging to a class. PDB has no info about namespaces, so this implementation parses the full symbol name and tries to figure out if the symbol belongs to namespace or not, and then creates nested namespaces if necessary. Reviewers: asmith, zturner, labath Reviewed By: asmith Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D51162 llvm-svn: 341782
* [PDB] Resolve a symbol context block info correctlyAleksandr Urakov2018-08-291-3/+7
| | | | | | | | | | | | | | | | | | | Summary: This patch allows to resolve a symbol context block info even if a function info was not requested. Also it adds the correct resolving of nested blocks (the previous implementation used function blocks instead of them). Reviewers: zturner, asmith, labath Reviewed By: asmith Subscribers: lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D51104 llvm-svn: 340901
* [PDB] Parse UDT symbols and pointers to members (combined patch)Aleksandr Urakov2018-08-141-7/+22
| | | | | | | | | | | | | | | | | | | | | | Summary: In this patch I've tried to combine the best ideas from D49368 and D49410, so it implements following: - Completion of UDTs from a PDB with a filling of a layout info; - Pointers to members; - Fixes the bug relating to a virtual base offset reading from `vbtable`. The offset was treated as an unsigned, but it can be a negative sometimes. - Support of MSInheritance attribute Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits Reviewed By: zturner Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D49980 llvm-svn: 339649
* Convert a location information from PDB to a DWARF expressionJonas Devlieghere2018-07-131-1/+5
| | | | | | | | | | | | | | | | | | The current version of SymbolFilePDB::ParseVariableForPDBData function always initializes variables with an empty location. This patch adds the converter of a location information from PDB to a DWARF expression, so it becomes possible to watch values of variables of primitive data types. At the moment the converter supports only Static, TLS, RegRel, Enregistered and Constant PDB location types, but it seems that it's enough for most cases. There are still some problems with retrieving values of variables (e.g. we can't watch variables of composite types), but they look not relevant to the conversion to DWARF. Patch by: Aleksandr Urakov Differential revision: https://reviews.llvm.org/D49018 llvm-svn: 336988
* Retrieve a function PDB symbol correctly from nested blocksPavel Labath2018-06-281-33/+34
| | | | | | | | | | | | | | | | | | | Summary: This patch fixes a problem with retrieving a function symbol by an address in a nested block. In the current implementation of ResolveSymbolContext function it retrieves a symbol with PDB_SymType::None and then checks if found symbol's tag equals to PDB_SymType::Function. So, if nested block's symbol was found, ResolveSymbolContext does not resolve a function. Reviewers: asmith, labath, zturner Reviewed By: asmith, labath Differential Revision: https://reviews.llvm.org/D47939 Patch by Aleksandr Urakov <aleksandr.urakov@jetbrains.com> llvm-svn: 335822
* PDB support of function-level linking and splitted functionsAaron Smith2018-06-081-0/+3
| | | | | | | | | | | | | | | | | | | Summary: The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature. SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0). To fix the problem this patch renews the sequence on each address gap. Reviewers: asmith, zturner Reviewed By: asmith Subscribers: aleksandr.urakov, labath, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47708 llvm-svn: 334260
* Revert "PDB support of function-level linking and splitted functions"Pavel Labath2018-06-061-3/+0
| | | | | | This reverts commit r334030 because it adds a broken test. llvm-svn: 334076
* PDB support of function-level linking and splitted functionsAaron Smith2018-06-051-0/+3
| | | | | | | | | | | | | | | | | | | Summary: The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature. SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0). To fix the problem this patch renews the sequence on each address gap. Reviewers: asmith, zturner Reviewed By: asmith Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D47708 llvm-svn: 334030
* Remove append parameter to FindGlobalVariablesPavel Labath2018-05-311-4/+2
| | | | | | | | | | | | | | | | | | | 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
* [SymbolFilePDB] Add support for resolving variable symbolsAaron Smith2018-05-231-4/+300
| | | | | | | | | | | | | | | | | 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
* FileSpec: Remove PathSyntax enum and use llvm version insteadPavel Labath2018-05-141-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-38/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [SymbolFilePDB] Use section contributions as another way to determine the ↵Aaron Smith2018-03-221-16/+19
| | | | | | | | | compiland 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
* [SymbolFilePDB] Ignore compiler generated functions when creating the LLDB ↵Aaron Smith2018-03-221-4/+4
| | | | | | type from a PDB llvm-svn: 328230
* [SymbolFilePDB] Run clang-format; NFCAaron Smith2018-03-221-79/+63
| | | | llvm-svn: 328176
* [SymbolFilePDB] Simplify code with newer methodsAaron Smith2018-03-201-14/+2
| | | | llvm-svn: 327927
* [SymbolFilePDB] Simplify getting the source file pathAaron Smith2018-03-201-63/+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-191-40/+30
| | | | | | | | | | | | 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] 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
* Fix some warnings in SymbolFilePDB.cppPavel Labath2018-02-091-7/+6
| | | | llvm-svn: 324730
* [SymbolFilePDB] Add support for function symbolsAaron Smith2018-02-091-12/+645
| | | | | | | | | | | | | | | | | | | | | | | 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
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-231-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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-221-35/+4
| | | | | | | | | | 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-191-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | 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-131-68/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Stop searching for a symbol in a pdb by regexAaron Smith2017-12-221-14/+11
| | | | | | | | | | | | | | | | | 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
* 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
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-599/+568
| | | | | | | | | | | | | | | | | | | | | | | *** 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-041-35/+37
| | | | | | | 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-151-8/+162
| | | | | | | | | | | | | | | | 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-021-0/+549
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