summaryrefslogtreecommitdiffstats
path: root/lldb
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] - Add support for DW_FORM_addrx[1-4]? forms.George Rimar2018-10-316-8/+124
| | | | | | | | | 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
* Fixup the Python-less build of ScriptedRecognizedStackFrameKuba Mracek2018-10-312-0/+6
| | | | llvm-svn: 345694
* [lldb] Introduce StackFrameRecognizer [take 3]Kuba Mracek2018-10-3124-16/+1163
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345693
* Revert r345686 due to build failuresKuba Mracek2018-10-3124-1162/+16
| | | | llvm-svn: 345688
* [lldb] Introduce StackFrameRecognizer [take 2]Kuba Mracek2018-10-3124-16/+1162
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345686
* Revert r345678 (build failure on Linux machines).Kuba Mracek2018-10-3124-1162/+16
| | | | llvm-svn: 345680
* [lldb] Introduce StackFrameRecognizerKuba Mracek2018-10-3124-16/+1162
| | | | | | | | This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector). Differential Revision: https://reviews.llvm.org/D44603 llvm-svn: 345678
* [testsuite] Skip an already failing test on MacOS.Davide Italiano2018-10-301-0/+1
| | | | | | | | Due to some libcxx changes to inlining, this now also crashes, so it gets reported as "failure" by the bot. This commit doesn't really change the status quo, just placates the bots. llvm-svn: 345668
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-303-8/+7
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [NativePDB] Add support for dumping global variables of class type.Zachary Turner2018-10-306-3/+345
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [x86] Fix issues with a realigned stack in MSVC compiled applicationsAleksandr Urakov2018-10-308-150/+484
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes issues with a stack realignment. MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one is used for access to function parameters, while another is used for access to locals. To support this the patch: - adds an alternative frame pointer (`ebx`); - considers stack realignment instructions (e.g. `and esp, -32`); - along with CFA (Canonical Frame Address) which point to the position next to the saved return address (or to the first parameter on the stack) introduces AFA (Aligned Frame Address) which points to the position of the stack pointer right after realignment. AFA is used for access to registers saved after the realignment (see the test); Here is an example of the code with the realignment: ``` struct __declspec(align(256)) OverAligned { char c; }; void foo(int foo_arg) { OverAligned oa_foo = { 1 }; auto aaa_foo = 1234; } void bar(int bar_arg) { OverAligned oa_bar = { 2 }; auto aaa_bar = 5678; foo(1111); } int main() { bar(2222); return 0; } ``` and here is the `bar` disassembly: ``` push ebx mov ebx, esp sub esp, 8 and esp, -100h add esp, 4 push ebp mov ebp, [ebx+4] mov [esp+4], ebp mov ebp, esp sub esp, 200h mov byte ptr [ebp-200h], 2 mov dword ptr [ebp-4], 5678 push 1111 ; foo_arg call j_?foo@@YAXH@Z ; foo(int) add esp, 4 mov esp, ebp pop ebp mov esp, ebx pop ebx retn ``` Reviewers: labath, zturner, jasonmolenda, stella.stamenova Reviewed By: jasonmolenda Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D53435 llvm-svn: 345577
* Utility: fix cross-compilation from Linux to WindowsSaleem Abdulrasool2018-10-301-1/+3
| | | | | | | | Only attempt to link against Backtrace if it is found. Without this, trying to cross-compile to Windows would try to link against "Backtrace_LIBRARY-NOTFOUND.lib". llvm-svn: 345569
* [lldb-mi] Implement -gdb-set breakpoint pending on/offMarc-Andre Laperle2018-10-309-3/+163
| | | | | | | | | | | | | | | | | | Summary: This allows creating pending breakpoint automatically when a location is not found. This is used by some front-ends instead of doing "-break-insert -f" every time. See also https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com> Subscribers: MaskRay, llvm-commits, lldb-commits, ki.stfu Tags: #lldb Differential Revision: https://reviews.llvm.org/D52953 llvm-svn: 345563
* [LLDB] - Fix outdated comment. NFC.George Rimar2018-10-291-2/+1
| | | | llvm-svn: 345498
* Fix and rename broken test for `settings write`.Jonas Devlieghere2018-10-261-10/+10
| | | | | | | | I committed this test without updating the old `settings export` to settings write. Since the functionality was renamed I also renamed the test case. llvm-svn: 345435
* Remove an early-return from Driver::ParseArgs thatJason Molenda2018-10-261-4/+0
| | | | | | | | | | was added as a part of D52604 / r343348. If the lldb driver is run without any arguments, .lldbinit file reading was not enabled. <rdar://problem/45570242> llvm-svn: 345422
* [DataFormatters] Adding formatters for libc++ std::u16string and std::u32stringShafik Yaghmour2018-10-266-12/+71
| | | | | | | | rdar://problem/41302849 Differential Revision: https://reviews.llvm.org/D53656 llvm-svn: 345402
* [Windows] Define generic arguments registers for Windows x64Aleksandr Urakov2018-10-261-6/+6
| | | | | | | | | | | | | | | | Summary: When evaluating expressions the generic arguments registers are required by ABI. This patch defines them. Reviewers: zturner, stella.stamenova, labath Subscribers: aleksandr.urakov, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D53753 llvm-svn: 345385
* [PDB] Fix `SymbolFilePDBTests` after r345313Aleksandr Urakov2018-10-261-2/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D53749 llvm-svn: 345374
* [NativePDB] Add the ability to dump dump global variables.Zachary Turner2018-10-265-17/+1087
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update test that checks auto-completion for settings set.Jonas Devlieghere2018-10-261-0/+5
| | | | | | | This reverts r345350 and updates the test rather than removing it. Now we check that `--g` auto-completes to `--global`. llvm-svn: 345351
* Remove test that checks auto-completion for settings set.Jonas Devlieghere2018-10-261-5/+0
| | | | | | | With the new `-f` option for `settings set`, `-` (dash) no longer auto-complete to `-g`. llvm-svn: 345350
* Add functionality to export settingsJonas Devlieghere2018-10-269-21/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the reproducer feature I need to be able to export and import the current LLDB configuration. To realize this I've extended the existing functionality to print settings. With the help of a new formatting option, we can now write the settings and their values to a file structured as regular commands. Concretely the functionality works as follows: (lldb) settings export -f /path/to/file This file contains a bunch of settings set commands, followed by the setting's name and value. ... settings set use-external-editor false settings set use-color true settings set auto-one-line-summaries true settings set auto-indent true ... You can import the settings again by either sourcing the file or using the settings read command. (lldb) settings read -f /path/to/file Differential revision: https://reviews.llvm.org/D52651 llvm-svn: 345346
* Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner2018-10-2528-152/+186
| | | | | | | | | | 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-2537-117/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-258-94/+87
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove accidentally committed duplicate codeAdrian Prantl2018-10-251-5/+0
| | | | llvm-svn: 345287
* Get rid of casts. (NFC)Adrian Prantl2018-10-252-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D53709 llvm-svn: 345278
* Fix a bug PlatformDarwin::SDKSupportsModule.Adrian Prantl2018-10-254-13/+41
| | | | | | | | | | | | | | | This fixes a bug PlatformDarwin::SDKSupportsModule introduced by https://reviews.llvm.org/D47889. VersionTuple::tryParse() can deal with an optional third (micro) component, but the parse will fail when there are extra characters after the version number (e.g.: trying to parse the substring "12.0.sdk" out of "iPhoneSimulator12.0.sdk" fails after that patch). Fixed here by stripping the ".sdk" suffix first. (Part of) rdar://problem/45041492 Differential Revision https://reviews.llvm.org/D53677 llvm-svn: 345274
* Recommit r345127 "[LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-257-54/+188
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDB] - Parse the DW_LLE_startx_length correctly for DWARF v5 case.George Rimar2018-10-252-5/+11
| | | | | | | | | | | | | | | | | | | | | Currently, we always parse the length field of DW_LLE_startx_length entry as U32. That is correct for pre-standard definition: https://gcc.gnu.org/wiki/DebugFission - "A start/length entry contains one unsigned LEB128 number and a 4-byte unsigned value (as would be represented by the form code DW_FORM_const4u). The first number is an index into the .debug_addr section that selects the beginning offset, and the second number is the length of the range. ") But DWARF v5 says: "This is a form of bounded location description that has two unsigned ULEB operands. The first value is an address index (into the .debug_addr section) that indicates the beginning of the address range over which the location is valid. The second value is the length of the range." Fortunately, we can easily handle the difference. No test case because it seems impossible to test until we will be ready to use DWARF v5 in tests that need to run the executables. Differential revision: https://reviews.llvm.org/D53646 llvm-svn: 345249
* [API] Extend the `SBThreadPlan` interfaceAleksandr Urakov2018-10-257-0/+108
| | | | | | | | | | | | | | | | | | Summary: This patch extends the `SBThreadPlan` to allow retrieving of thread plans for scripted steps. Reviewers: labath, zturner, jingham Reviewed By: jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D53361 llvm-svn: 345247
* [Settings] Add -force flag to "settings set"Jonas Devlieghere2018-10-242-3/+38
| | | | | | | | | | | | | | | | | | | The -force option allows you to pass an empty value to settings set to reset the value to its default. This means that the following operations are equivalent: settings set -f <setting> settings clear <setting> The motivation for this change is the ability to export and import settings from LLDB. Because of the way the dumpers work, we don't know whether a value is going to be the default or not. Hence we cannot use settings clear and use settings set -f, potentially providing an empty value. Differential revision: https://reviews.llvm.org/D52772 llvm-svn: 345207
* Revert rL345127: [LLDB] - Add support for DW_RLE_base_address and ↵George Rimar2018-10-247-185/+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] Remove enableThreadSanitizer from shared Xcode schemesKuba Mracek2018-10-242-2/+0
| | | | | | This was probably committed accidentally and default Xcode builds of LLDB now have TSan on. Let's turn it off. llvm-svn: 345155
* [LLDB] - Add support for DW_RLE_base_address and DW_RLE_offset_pair entries ↵George Rimar2018-10-247-54/+185
| | | | | | | | | | | (.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
* Support nwere versions of the Segger J-Link jtag board software.Jason Molenda2018-10-235-6/+184
| | | | | | | | | | | | | | | | | | | | | | Add support in ProcessGDBRemote::GetGDBServerRegisterInfo for recognizing a generic "arm" architecture that will be used if nothing better is available so that we don't ignore the register definitions if we didn't already have an architecture set. Also in ProcessGDBRemote::DoConnectRemote don't set the target arch unless we have a valid architecture to set it to. Platform::ConnectProcess will try to get the current target's architecture, or the default architecture, when creating the target for the connection to be attempted. If lldb was started with a target binary, we want to create this target with that architecture in case the remote gdb stub doesn't supply a qHostInfo arch. Add logging to Target::MergeArchitecture. <rdar://problem/34916465> llvm-svn: 345106
* 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
* Add UdtRecordCompleter.cpp.Jason Molenda2018-10-231-0/+6
| | | | llvm-svn: 345069
* Skip test with older versions of clangJonas Devlieghere2018-10-231-0/+1
| | | | | | | | | This was failing for the bots that build with older clangs: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-5.0.2/ http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-clang-6.0.1/ llvm-svn: 345061
* Change two methods from const char* to StringRef [NFC].Zachary Turner2018-10-234-41/+48
| | | | llvm-svn: 345055
* [NativePDB] Add basic support for tag types to the native pdb plugin.Zachary Turner2018-10-238-3/+1246
| | | | | | | | | | | | | | | | | 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-2313-4/+55
| | | | | | | | | | | 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
* [ValueObject] Stop assuming types are non-zero sized.Davide Italiano2018-10-231-1/+7
| | | | | | | | | | Some backends might violate this assumption. No test case upstream unfortunately as this is not the case with C++, but I'm going to add a test in swift language support. <rdar://problem/40962410> llvm-svn: 344982
* Fix typo in ASSERT_MODULE_LOCK macro definitionJonas Devlieghere2018-10-231-1/+1
| | | | llvm-svn: 344979
* [DWARF] Use a function-local offset for AT_call_return_pcVedant Kumar2018-10-222-5/+6
| | | | | | | | | | | | | | | | | | | Logs provided by @stella.stamenova indicate that on Linux, lldb adds a spurious slide offset to the return PC it loads from AT_call_return_pc attributes (see the list thread: "[PATCH] D50478: Add support for artificial tail call frames"). This patch side-steps the issue by getting rid of the load address calculation in lldb's CallEdge::GetReturnPCAddress. The idea is to have the DWARF writer emit function-local offsets to the instruction after a call. I.e. return-pc = label-after-call-insn - function-entry. LLDB can simply add this offset to the base address of a function to get the return PC. Differential Revision: https://reviews.llvm.org/D53469 llvm-svn: 344960
* [SymbolFile] Add the module lock where necessary and assert that we own it.Jonas Devlieghere2018-10-224-4/+81
| | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud