summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/SymbolFile
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove header grouping comments.Jonas Devlieghere2018-11-1114-50/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Remove comments after header includes.Jonas Devlieghere2018-11-112-2/+2
| | | | | | | | | | This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
* [NativePDB] Fix completion of enum types.Zachary Turner2018-11-091-0/+1
| | | | | | | | | | | | | This was originally submitted in a patch which fixed two unrelated bugs at the same time. This portion of the fix was reverted because it broke several other things. However, the fix employed originally was totally wrong, and attempted to change something in the ValueObject printer when actually the bug was in the NativePDB plugin. We need to mark forward enum decls as having external storage, otherwise we won't be asked to complete them when the time comes. This patch implements the proper fix, and updates tests accordingly. llvm-svn: 346517
* [NativePDB] Add support for bitfield records.Zachary Turner2018-11-091-4/+20
| | | | | | | | | Bitfields are represented as LF_MEMBER records whose TypeIndex points to an LF_BITFIELD record that describes the bit width, bit offset, and underlying type of the bitfield. All we need to do is resolve these when resolving record types. llvm-svn: 346511
* [lldb] Fix initialization order warnings.Jorge Gorbe Moya2018-11-081-1/+1
| | | | | | | | | | | | | | | Moved the declaration of m_kind below the declaration of cvclass, cvunion and cvenum. This order is necessary because in one of the constructors the initialization of m_kind depends on the value of cvclass. third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:50:7: error: field 'cvclass' will be initialized after field 'm_kind' [-Werror,-Wreorder] : cvclass(std::move(c)), ^ third_party/llvm/llvm/tools/lldb/source/Plugins/SymbolFile/NativePDB/PdbUtil.cpp:51:14: error: field 'cvclass' is uninitialized when used here [-Werror,-Wuninitialized] m_kind(cvclass.Kind == TypeRecordKind::Struct ? Struct : Class) {} llvm-svn: 346435
* [NativePDB] Higher fidelity reconstruction of AST from Debug Info.Zachary Turner2018-11-084-18/+221
| | | | | | | | | | | | | | | | | | | | | | | | | In order to accurately put a type into the correct location in the AST we construct from debug info, we need to be able to determine what DeclContext (namespace, global, nested class, etc) that it goes into. PDB doesn't contain this mapping. It does, however, contain the reverse mapping. That is, for a given class type T, you can determine all classes Q1, Q2, ..., Qn that are nested inside of T. We need to know, for a given class type Q, what type T is it nested inside of. This patch builds this map as a pre-processing step when we first load the PDB by scanning every type. Initial tests show that while this can be slow in debug builds of LLDB, it is quite fast in release builds (less than 2 seconds for a ~1GB PDB, and it only needs to happen once). Furthermore, having this pre-processing step in place allows us to repurpose it for building up other kinds of indexing to it down the line. For the time being, this gives us very accurate reconstruction of the DeclContext hierarchy. Differential Revision: https://reviews.llvm.org/D54216 llvm-svn: 346429
* Refactor ClangASTContext::AddEnumerationValueToEnumerationType() to remove ↵Shafik Yaghmour2018-11-083-11/+4
| | | | | | | | | | redundant parameter which can be calculated from other parameter. rdar://problem/43822994 Differential Revision: https://reviews.llvm.org/D54003 llvm-svn: 346428
* [PDB] Introduce `MSVCUndecoratedNameParser`Aleksandr Urakov2018-11-064-121/+155
| | | | | | | | | | | | This patch introduces the simple MSVCUndecoratedNameParser. It is needed for parsing names of PDB symbols corresponding to template instantiations. For example, for the name `operator<<A>'::`2'::B::operator> we can't just split the name with :: (as it is implemented for now) to retrieve its scopes. This parser processes such names in a more correct way. Differential Revision: https://reviews.llvm.org/D52461 llvm-svn: 346213
* Fix (and improve) the support for C99 variable length array typesAdrian Prantl2018-11-0513-23/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this: 0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) ) 0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} ) Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types. See the testcase for an example: 4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 } (lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit rdar://problem/21814005 Differential Revision: https://reviews.llvm.org/D53530 llvm-svn: 346165
* Remove OCaml debugger pluginJonas Devlieghere2018-11-054-271/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the OCaml debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54060 llvm-svn: 346159
* Remove Java debugger pluginJonas Devlieghere2018-11-054-594/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Java debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54059 llvm-svn: 346158
* Remove Go debugger pluginJonas Devlieghere2018-11-053-857/+0
| | | | | | | | | | | | | | | | | | | In January Davide sent an e-mail to the mailing list to suggest removing unmaintained language plugins such as Go and Java. The plan was to have some cool down period to allow users to speak up, however after that the plugins were never actually removed. This patch removes the Go debugger plugin. The plugin can be added again in the future if it is mature enough both in terms of testing and maintenance commitment. Discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html Differential revision: https://reviews.llvm.org/D54057 llvm-svn: 346157
* Add a target modules dump ast command.Zachary Turner2018-11-059-1/+38
| | | | | | | | | | This is useful for investigating the clang ast as you reconstruct it via by parsing debug info. It can also be used to write tests against. Differential Revision: https://reviews.llvm.org/D54072 llvm-svn: 346149
* Revert "[Symbol] Search symbols with name and type in a symbol file"Davide Italiano2018-11-022-51/+0
| | | | | | It broke MacOS buildbots. llvm-svn: 346045
* [LLDB] - Add support for DW_FORM_rnglistx and relative DW_RLE_* entries.George Rimar2018-11-025-21/+90
| | | | | | | | | This adds support for DW_RLE_base_addressx, DW_RLE_startx_endx, DW_RLE_startx_length, DW_FORM_rnglistx. Differential revision: https://reviews.llvm.org/D53929 llvm-svn: 345958
* [Symbol] Search symbols with name and type in a symbol fileAleksandr Urakov2018-11-022-0/+51
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds possibility of searching a public symbol with name and type in a symbol file. It is helpful when working with PE, because PE's symtabs contain only imported / exported symbols only. Such a search is required for e.g. evaluation of an expression that calls some function of the debuggee. Reviewers: zturner, asmith, labath, clayborg, espindola Reviewed By: clayborg Subscribers: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D53368 llvm-svn: 345957
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-016-19/+21
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* [FileSystem] Remove Exists() from FileSpecJonas Devlieghere2018-11-012-3/+3
| | | | | | | | | This patch removes the Exists method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53845 llvm-svn: 345854
* [NativePDB] Get LLDB types from PDB function types.Zachary Turner2018-11-013-8/+106
| | | | | | | | | | | | | | This adds basic support for getting function signature types into LLDB's type system, including into clang's AST. There are a few edge cases which are not correctly handled, mostly dealing with nested classes, but this isn't specific to functions and apply equally to variable types. Note that no attempt has been made yet to deal with member function types, which will happen in subsequent patches. Differential Revision: https://reviews.llvm.org/D53951 llvm-svn: 345848
* [FileSystem] Remove GetByteSize() from FileSpecJonas Devlieghere2018-11-012-2/+4
| | | | | | | | | This patch removes the GetByteSize method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53788 llvm-svn: 345812
* [FileSystem] Extend file system and have it use the VFS.Jonas Devlieghere2018-10-312-2/+2
| | | | | | | | | | | | | | | | This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These methods will be removed in future commits and replaced by calls to the file system. The new functions are operated in terms of the virtual file system which was recently moved from clang into LLVM so it could be reused in lldb. Because the VFS is stateful, we turned the FileSystem class into a singleton. Differential revision: https://reviews.llvm.org/D53532 llvm-svn: 345783
* [LLDB] - Regroup the switch entries in DWARFFormValue::ExtractValue. NFC.George Rimar2018-10-311-60/+26
| | | | | | | | This is NFC to clean up the `DWARFFormValue::ExtractValue`. It groups similar `DW_FORM_*` and removes an excessive assignment of `ref_addr_size` (it was assigned right after in any case). llvm-svn: 345733
* [LLDB] - Removed unused variable. NFC.George Rimar2018-10-311-4/+1
| | | | | | | | Introduced in r344119. Thanks to Dávid Bolvanský fo reporting. llvm-svn: 345720
* [LLDB] - Add support for DW_FORM_addrx[1-4]? forms.George Rimar2018-10-314-8/+37
| | | | | | | | | This adds the support for DW_FORM_addrx, DW_FORM_addrx1, DW_FORM_addrx2, DW_FORM_addrx3, DW_FORM_addrx4 forms. Differential revision: https://reviews.llvm.org/D53813 llvm-svn: 345706
* [NativePDB] Add support for dumping global variables of class type.Zachary Turner2018-10-304-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | | Previous patches added support for dumping global variables of primitive types, so we now do the same for class types. For the most part, everything just worked, there was only one minor bug needing fixed, which was that for variables of modified types (e.g. const, volatile, etc) we can't resolve the forward decl in CreateAndCacheType because the PdbSymUid must point to the LF_MODIFIER which must point to the forward decl. So when it comes time to call CompleteType, an assert was firing because we expected to get a class, struct, union, or enum, but we were getting an LF_MODIFIER instead. The other issue is that one the newly added tests is for an array member, which was not yet supported, so we add support for that now in this patch. There's probably room for other interesting layout test cases here, but this at least should test the basics. Differential Revision: https://reviews.llvm.org/D53822 llvm-svn: 345629
* [LLDB] - Fix outdated comment. NFC.George Rimar2018-10-291-2/+1
| | | | llvm-svn: 345498
* [NativePDB] Add the ability to dump dump global variables.Zachary Turner2018-10-263-17/+199
| | | | | | | | | | | | | | | | | | | | | | | | | LLDB has the ability to display global variables, even without a running process, via the target variable command. This is because global variables are linker initialized, so their values are embedded directly into the executables. This gives us great power for testing native PDB functionality in a cross-platform manner, because we don't actually need a running process. We can just create a target using an EXE file, and display global variables. And global variables can have arbitrarily complex types, so in theory we can fully exercise the type system, record layout, and data formatters for native PDB files and PE/COFF executables on any host platform, as long as our type does not require a dynamic initializer. This patch adds basic support for finding variables by name, and adds an exhaustive test for fundamental data types and pointers / references to fundamental data types. Subsequent patches will extend this to typedefs, classes, pointers to functions, and other cases. Differential Revision: https://reviews.llvm.org/D53731 llvm-svn: 345373
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-2510-26/+26
| | | | | | | | | | This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
* Don't type-erase the SymbolContextItem enumeration.Zachary Turner2018-10-2510-19/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Refactor SetBaseClasses and DeleteBaseClasses.Zachary Turner2018-10-255-49/+45
| | | | | | | | | | | | | | | | | | | | | | We currently had a 2-step process where we had to call SetBaseClassesForType and DeleteBaseClasses. Every single caller followed this exact 2-step process, and there was manual memory management going on with raw pointers. We can do better than this by storing a vector of unique_ptrs and passing this around. This makes for a cleaner API, and we only need to call one method so there is no possibility of a user forgetting to call DeleteBaseClassSpecifiers. In addition to this, it also makes for a *simpler* API. Part of why I wanted to do this is because when I was implementing the native PDB interface I had to spend some time understanding exactly what I was deleting and why. ClangAST has significant mental overhead associated with it, and reducing the API surface can go along way to making it simpler for people to understand. Differential Revision: https://reviews.llvm.org/D53590 llvm-svn: 345312
* Recommit r345127 "[LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-255-54/+102
| | | | | | | | | | | | | | | | | | | | | | | | DW_RLE_offset_pair entries (.debug_rnglists)" With the fix: do not forget to hanlde the DW_RLE_start_end, which seems was omited/forgotten/removed by mistake. Original commit message: The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair .debug_rnglists entries Differential revision: https://reviews.llvm.org/D53140 ---- Added : /lldb/trunk/lit/Breakpoint/Inputs/debug_rnglist_offset_pair.yaml Added : /lldb/trunk/lit/Breakpoint/debug_rnglist_offset_pair.test Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Modified : /lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h llvm-svn: 345251
* Revert rL345127: [LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-245-99/+54
| | | | | | | | | DW_RLE_offset_pair entries It broke BB: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/11671/consoleFull#434797663d489585b-5106-414a-ac11-3ff90657619c llvm-svn: 345157
* [LLDB] - Add support for DW_RLE_base_address and DW_RLE_offset_pair entries ↵George Rimar2018-10-245-54/+99
| | | | | | | | | | | (.debug_rnglists) The patch implements the support for DW_RLE_base_address and DW_RLE_offset_pair .debug_rnglists entries Differential revision: https://reviews.llvm.org/D53140 llvm-svn: 345127
* Remove unused private methods.Zachary Turner2018-10-231-8/+0
| | | | llvm-svn: 345092
* Fix some comments pointed out by Leonard Mosescu.Zachary Turner2018-10-231-4/+4
| | | | | | | These were originally pointed out in D53511 but I forgot to incorporate them in my patch. llvm-svn: 345091
* Remove unused variable.Eric Christopher2018-10-231-1/+0
| | | | llvm-svn: 345086
* Change two methods from const char* to StringRef [NFC].Zachary Turner2018-10-232-5/+3
| | | | llvm-svn: 345055
* [NativePDB] Add basic support for tag types to the native pdb plugin.Zachary Turner2018-10-236-3/+1002
| | | | | | | | | | | | | | | | | This adds support to LLDB for named types (class, struct, union, and enum). This is true cross platform support, and hits the PDB file directly without a dependency on Windows. Tests are added which compile a program with certain interesting types and then use load the target in LLDB and use "type lookup -- <TypeName>" to dump the layout of the type in LLDB without a running process. Currently only fields are parsed -- we do not parse methods. Also we don't deal with bitfields or virtual bases correctly. Those will make good followups. Differential Revision: https://reviews.llvm.org/D53511 llvm-svn: 345047
* [LLDB] - Implement the support for the .debug_loclists section.George Rimar2018-10-234-4/+22
| | | | | | | | | | | This implements the support for .debug_loclists section, which is DWARF 5 version of .debug_loc. Currently, clang is able to emit it with the use of D53365. Differential revision: https://reviews.llvm.org/D53436 llvm-svn: 345016
* [PDB] Improve performance of the PDB DIA pluginAleksandr Urakov2018-10-232-25/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [SymbolFile] Add the module lock where necessary and assert that we own it.Jonas Devlieghere2018-10-222-4/+45
| | | | | | | | | | | | | | | As discussed with Greg at the dev meeting, we need to ensure we have the module lock in the SymbolFile. Usually the symbol file is accessed through the symbol vendor which ensures that the necessary locks are taken. However, there are a few methods that are accessed by the expression parser and were lacking the lock. This patch adds the locking where necessary and everywhere else asserts that we actually already own the lock. Differential revision: https://reviews.llvm.org/D52543 llvm-svn: 344945
* Some cleanups to the native pdb plugin [NFC].Zachary Turner2018-10-225-130/+244
| | | | | | | | | | | This is mostly some cleanup done in the process of implementing some basic support for types. I tried to split up the patch a bit to get some of the NFC portion of the patch out into a separate commit, and this is the result of that. It moves some code around, deletes some spurious namespace qualifications, removes some unnecessary header includes, forward declarations, etc. llvm-svn: 344913
* [SymbolFileNativePDB] Fix missing linkage to DebugInfoCodeViewMichal Gorny2018-10-181-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D53402 llvm-svn: 344746
* [LLDB] - Add support for DW_RLE_start_end entries (.debug_rnglists)George Rimar2018-10-171-1/+8
| | | | | | | | | | | | | | | DWARF5 describes DW_RLE_start_end as: This is a form of bounded range entry that has two target address operands. Each operand is the same size as used in DW_FORM_addr. These indicate the starting and ending addresses, respectively, that define the address range for which the following location is valid. The patch implements the support. Differential revision: https://reviews.llvm.org/D53193 llvm-svn: 344674
* Code cleanup: Remove DWARFDebugInfoEntry::m_empty_childrenJan Kratochvil2018-10-163-22/+14
| | | | | | | | | | | | | | | | | | | | | | | It merges DWARFDebugInfoEntry's m_empty_children into m_has_children. m_empty_children was implemented by rL144983. As Greg confirmed m_has_children was used to represent what was in the DWARF in the byte that follows the DW_TAG. m_empty_children was used for DIEs that said they had children but actually only contain a single NULL tag. It is fine to not differentiate between the two. Also changed assert()->lldbassert() for m_abbr_idx 16-bit overflow check as that could be a tough bug to catch if it ever happens. I have checked all calls of HasChildren() that this change should not matter to them. The code even wants to know if there are any children - it does not matter how the children presence is coded in the binary. Patch written based on suggestions by Greg Clayton. Differential Revision: https://reviews.llvm.org/D53321 llvm-svn: 344644
* Fix: Assertion failed: (!m_first_die || m_first_die == m_die_array.front()), ↵Jan Kratochvil2018-10-161-1/+5
| | | | | | | | | | | | | | | | function ExtractDIEsRWLocked xbolva00 bugreported $subj in: https://reviews.llvm.org/D46810#1247410 It can happen only from the line: m_die_array.back().SetEmptyChildren(true); In the case DW_TAG_compile_unit has DW_CHILDREN_yes but there is only 0 (end of list, no children present). Therefore the assertion can fortunately happen only with a hand-crafted DWARF or with DWARF from some suboptimal compilers. Differential Revision: https://reviews.llvm.org/D53255 llvm-svn: 344605
* Try to fix some failures on MacOSX with the NativePDB patch.Zachary Turner2018-10-121-2/+9
| | | | | | | | | | This adds -- before any filenames, so that /U doesn't get interpreted as a command line. It also adds better error checking, so that we don't get assertions on the failure path when a file fails to parse as a PDB. llvm-svn: 344429
* Resubmit "Add SymbolFileNativePDB plugin."Zachary Turner2018-10-1213-4/+2049
| | | | | | | | | | 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
* [LLDB] - Add support for DW_FORM_implicit_const.George Rimar2018-10-128-51/+63
| | | | | | | | | | | | | | | LLDB does not support this DWARF5 form atm. At least gcc emits it in some cases when doing optimization for abbreviations. As far I can tell, clang does not support it yet, though the rest LLVM code already knows about it. The patch adds the support. Differential revision: https://reviews.llvm.org/D52689 llvm-svn: 344328
OpenPOWER on IntegriCloud