summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Core
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Add a SubsystemRAII that takes care of calling Initialize and ↵Raphael Isemann2019-12-231-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
* [LLDB] Fix handling for the clang name mangling extension for block invocationsshafik2019-11-061-0/+11
| | | | | | Add support for clangs mangling extension for block invocations. Differential Revision: https://reviews.llvm.org/D69738
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-1/+2
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* Remove the is_mangled flag from Mangled and SymbolAdrian Prantl2019-10-091-6/+2
| | | | | | | | | | | | | | | Testing whether a name is mangled or not is extremely cheap and can be done by looking at the first two characters. Mangled knows how to do it. On the flip side, many call sites that currently pass in an is_mangled determination do not know how to correctly do it (for example, they leave out Swift mangling prefixes). This patch removes this entry point and just forced Mangled to determine the mangledness of a string itself. Differential Revision: https://reviews.llvm.org/D68674 llvm-svn: 374180
* unittests: Use yaml2obj as a library instead of an external processPavel Labath2019-08-203-143/+107
| | | | | | | | | | | | | | | Summary: Recently, yaml2obj has been turned into a library. This means we can use it from our unit tests directly, instead of shelling out to an external process. This patch does just that. Reviewers: JDevlieghere, aadsm, espindola, jdoerfert Subscribers: emaste, mgorny, arichardson, MaskRay, jhenderson, abrachet, lldb-commits Differential Revision: https://reviews.llvm.org/D65949 llvm-svn: 369374
* SymbolVendor: Move Symtab construction into the SymbolFilePavel Labath2019-07-262-4/+4
| | | | | | | | | | | | | | | Summary: Instead of having SymbolVendor coordinate Symtab construction between Symbol and Object files, make the SymbolVendor function a passthrough, and put all of the logic into the SymbolFile. Reviewers: clayborg, JDevlieghere, jingham, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65208 llvm-svn: 367086
* Make UniqueCStringMap work with non-default-constructible types and other ↵Pavel Labath2019-06-142-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | improvements/cleanups Summary: The motivation for this was me wanting to make the validity of dwarf DIERefs explicit (via llvm::Optional<DIERef>). This meant that the class would no longer have a default constructor. As the DIERef was being stored in a UniqueCStringMap, this meant that this container (like all standard containers) needed to work with non-default-constructible types too. This part is achieved by removing the default constructors for the map entry types, and providing appropriate comparison overloads so that we can search for map entries without constructing a dummy entry. While doing that, I took the opportunity to modernize the code, and add some tests. Functions that were completely unused are deleted. This required also some changes in the Symtab code, as it was default constructing map entries, which was not impossible even though its value type was default-constructible. Technically, these changes could be avoided with some SFINAE on the entry type, but I felt that the code is cleaner this way anyway. Reviewers: JDevlieghere, sgraenitz Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D63268 llvm-svn: 363357
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-062-25/+4
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* [LLDB] - Update the test cases after yaml2obj change.George Rimar2019-04-031-80/+93
| | | | | | | | | https://reviews.llvm.org/D60122 (r357595) changed the symbols description format in yaml2obj. This change updates the LLDB tests. llvm-svn: 357600
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-2/+2
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Move RangeMap.h into UtilityPavel Labath2019-03-063-385/+0
| | | | | | | | | | | | | | Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-195-20/+15
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* RangeMap.h: merge RangeDataArray and RangeDataVectorPavel Labath2019-01-042-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main difference between the classes was supposed to be the fact that one is backed by llvm::SmallVector, and the other by std::vector. However, over the years, they have accumulated various other differences too. This essentially removes the std::vector version, as that is pretty much identical to llvm::SmallVector<T, 0>, and combines their interfaces. It does not attempt to do a more significant refactoring, even though there is still a lot of duplication in this file, as it is hard to tell which quirk of some API is depended on by somebody (and, a previous, more ambitious attempt at this in D16769 has failed). I also add some tests, including one which demonstrates one of the quirks/bugs of the API I have noticed in the process. Reviewers: clayborg, teemperor, tberghammer Subscribers: mgorny, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56170 llvm-svn: 350380
* Move Broadcaster+Listener+Event combo from Core into UtilityPavel Labath2018-12-144-217/+0
| | | | | | | | | | | | | | | | | | Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module. This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board. Reviewers: zturner, jingham, teemperor, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D55361 llvm-svn: 349157
* Move DataExtractorTest to unittests/UtilityPavel Labath2018-11-142-169/+0
| | | | | | | | The DataExtractor class itself was moved to Utility some time ago, but it seems this was not reflected in the location of the test code. Fix that. llvm-svn: 346867
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | 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
* [FileSystem] Extend file system and have it use the VFS.Jonas Devlieghere2018-10-311-0/+3
| | | | | | | | | | | | | | | | 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
* Fix typos.Bruce Mitchener2018-10-042-3/+3
| | | | | | | | | | Reviewers: lldb-commits Subscribers: srhines, ki.stfu Differential Revision: https://reviews.llvm.org/D52884 llvm-svn: 343825
* [lldb] Remove an assertion in RichManglingContext::GetBufferRef() hit when ↵Aaron Smith2018-09-281-0/+23
| | | | | | | | | | | | | | | | debugging a native x86 Windows process Summary: A RichManglingContext constructed with an invalid demangled name or with a demangled function name without any context will have an empty context. This triggers an assertion in RichManglingContext::GetBufferRef() when debugging a native Windows process on x86 when it shouldn't. Remove the assertion. Reviewers: aleksandr.urakov, zturner, lldb-commits Reviewed By: zturner Subscribers: erik.pilkington Differential Revision: https://reviews.llvm.org/D52626 llvm-svn: 343292
* Move Predicate.h from Host to UtilityRaphael Isemann2018-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class was initially in Host because its implementation used to be very OS-specific. However, with C++11, it has become a very simple std::condition_variable wrapper, with no host-specific code. It is also a general purpose utility class, so it makes sense for it to live in a place where it can be used by everyone. This has no effect on the layering right now, but it enables me to later move the Listener+Broadcaster+Event combo to a lower layer, which is important, as these are used in a lot of places (notably for launching a process in Host code). Reviewers: jingham, zturner, teemperor Reviewed By: zturner Subscribers: xiaobai, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50384 llvm-svn: 341089
* Added test for Core/Range class.Raphael Isemann2018-08-132-0/+331
| | | | | | | | | | | | | | | | | | | | Summary: We can optimize and refactor some of the classes in RangeMap.h, but first we should have some tests for all the data structures in there. This adds a first batch of tests for the Range class itself. There are some unexpected results happening when mixing invalid and valid ranges, so I added some FIXME's for that in the tests. Reviewers: vsk Reviewed By: vsk Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50620 llvm-svn: 339611
* RichManglingContext: Make m_ipd_str_len a local variable and simplify ↵Stefan Granitz2018-08-101-9/+12
| | | | | | processIPDStrResult + polishing in test and Mangled llvm-svn: 339440
* Use rich mangling information in Symtab::InitNameIndexes()Stefan Granitz2018-08-082-0/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I set up a new review, because not all the code I touched was marked as a change in old one anymore. In preparation for this review, there were two earlier ones: * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function Primary goals for this patch are: (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index. (2) Provide a uniform interface. (3) Improve indexing performance. The central implementation in this patch is our new function for explicit demangling: ``` const RichManglingInfo * Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *) ``` It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are: * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`). * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing. The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`. Future potential: * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.) * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages. One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess). First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think. Reviewers: labath, jingham, JDevlieghere, erik.pilkington Subscribers: zturner, clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50071 llvm-svn: 339291
* Move ScalarTest to follow the class being testedPavel Labath2018-08-072-222/+0
| | | | | | This should have been a part of r339127, but I missed it somehow. llvm-svn: 339136
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-073-23/+1
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Unit test for Symtab::InitNameIndexesStefan Granitz2018-08-023-1/+261
| | | | | | | | | | | | | | Summary: In order to exploit the potential of LLVM's new ItaniumPartialDemangler for indexing in LLDB, we expect conceptual changes in the implementation of the InitNameIndexes function. Here is a unit test that aims at covering all relevant code paths in that function. Reviewers: labath, jingham, JDevlieghere Reviewed By: JDevlieghere Subscribers: friss, teemperor, davide, clayborg, erik.pilkington, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D49909 llvm-svn: 338695
* Use LLVM's new ItaniumPartialDemangler in LLDBStefan Granitz2018-07-252-0/+39
| | | | | | | | | | | | | | | Summary: Replace the existing combination of FastDemangle and the fallback to llvm::itaniumDemangle() with LLVM's new ItaniumPartialDemangler. It slightly reduces complexity and slightly improves performance, but doesn't introduce conceptual changes. This patch is preparing for more fundamental improvements on LLDB's demangling approach. Reviewers: friss, jingham, erik.pilkington, labath, clayborg, mgorny, davide, JDevlieghere Reviewed By: JDevlieghere Subscribers: teemperor, JDevlieghere, labath, clayborg, davide, lldb-commits, mgorny, erik.pilkington Differential Revision: https://reviews.llvm.org/D49612 llvm-svn: 337931
* Reimplement EventDataBytes::Dump to avoid DumpDataExtractorPavel Labath2018-07-242-0/+26
| | | | | | This is the only external non-trivial dependency of the Event classes. llvm-svn: 337819
* Scalar: Use llvm integer conversion functionsPavel Labath2018-06-192-0/+34
| | | | | | | | | | StringConvert was the only non-Utility dependency of this class. Getting rid of it means it will be easy to move this class to a lower layer. While I was in there, I also added a couple of unit tests for the Scalar string conversion function. llvm-svn: 335060
* Fix narrowing warning by appending `f` to literal constant.Adrian McCarthy2018-04-191-1/+1
| | | | llvm-svn: 330354
* [Core] Grab-bag of improvements for Scalar.Davide Italiano2018-04-021-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove Scalar::Cast. It was noted on the list that this method is unused. So, this patch removes it. Fix Scalar::Promote for most integer types This fixes promotion of most integer types (128- and 256-bit types are handled in a subsequent patch) to floating-point types. Previously promotion was done bitwise, where value preservation is correct. Fix Scalar::Promote for 128- and 256-bit integer types This patch fixes the behavior of Scalar::Promote when trying to perform a binary operation involving a 128- or 256-bit integer type and a floating-point type. Now, the integer is cast to the floating point type for the operation. Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44907 llvm-svn: 328985
* [Core] Correctly handle float division in Scalar.Davide Italiano2018-03-271-0/+8
| | | | | | | | Patch by Tom Tromey! Differential Revision: https://reviews.llvm.org/D44693 llvm-svn: 328649
* Fix unrepresentable float value in ScalarTestRaphael Isemann2018-01-221-1/+1
| | | | | | | | | | | | Summary: float can't represent the given value in the literal, so we get this UB error: `runtime error: 1.23457e+48 is outside the range of representable values of type 'float'`. The test seems to not rely on this specific value, so let's just choose a smaller one that can be represented. Reviewers: uweigand Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D42338 llvm-svn: 323081
* Move ArchSpec to the Utility modulePavel Labath2017-11-132-156/+0
| | | | | | | | | | | | | The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
* Fix dumping of characters with non-standard sizesPetr Pavlu2017-10-111-0/+117
| | | | | | | | | | | | | | | | * Prevent dumping of characters in DumpDataExtractor() with item_byte_size bigger than 8 bytes. This case is not supported by the code and results in a crash because the code calls DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for byte size > 8 bytes. * Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and GetMaxU64_unchecked() how to handle byte sizes that are not a multiple of 2. This allows DumpDataExtractor() to dump characters and booleans with item_byte_size in the interval of [1, 8] bytes. Values that are not a multiple of 2 would previously result in a crash because they were not handled by GetMaxU64(). llvm-svn: 315444
* Move Timer and TraceOptions from Core to UtilityPavel Labath2017-06-292-74/+0
| | | | | | | | | | | | | | Summary: The classes have no dependencies, and they are used both by lldb and lldb-server, so it makes sense for them to live in the lowest layers. Reviewers: zturner, jingham Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34746 llvm-svn: 306682
* Move StructuredData from Core to UtilityPavel Labath2017-06-272-33/+0
| | | | | | | | | | | | | | | | Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations. I've added a unit test to demonstrate that parsing a file still works. Reviewers: zturner, jingham Subscribers: kubamracek, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34625 llvm-svn: 306394
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-072-2/+2
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Remove an expensive lock from TimerPavel Labath2017-05-151-5/+12
| | | | | | | | | | | | | The Timer destructor would grab a global mutex in order to update execution time. Add a class to define a category once, statically; the class adds itself to an atomic singly linked list, and thus subsequent updates only need to use an atomic rather than grab a lock and perform a hashtable lookup. Differential Revision: https://reviews.llvm.org/D32823 Patch by Scott Smith <scott.smith@purestorage.com>. llvm-svn: 303058
* Rename Error -> Status.Zachary Turner2017-05-121-3/+3
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Recompute ArchSpec core after MergeFromPavel Labath2017-04-201-0/+19
| | | | | | | | | | | | | | | | | | Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
* Fix build failure in unit test.Zachary Turner2017-04-061-0/+1
| | | | llvm-svn: 299718
* Move many other files from Core -> Utility.Zachary Turner2017-03-061-1/+1
| | | | llvm-svn: 297043
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-042-2/+2
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-032-213/+0
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* [Windows] Remove the #include <eh.h> hack.Zachary Turner2017-03-033-20/+0
| | | | | | | | | | Prior to MSVC 2015 we had to manually include this header any time we were going to include <thread> or <future> due to a bug in MSVC's STL implementation. This has been fixed in MSVC for some time now, and we require VS 2015 minimum, so we can remove this across all subprojects. llvm-svn: 296906
* Fix gcc compilation of LogTest.cppPavel Labath2017-03-011-1/+1
| | | | llvm-svn: 296595
* Modernize Enable/DisableLogChannel interface a bitPavel Labath2017-03-011-13/+13
| | | | | | | | | | | | | | Summary: Use StringRef and ArrayRef where possible. This adds an accessor to the Args class to get a view of the arguments as ArrayRef<const char *>. Reviewers: zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30402 llvm-svn: 296592
* Log: Fix a regression in handling log optionsPavel Labath2017-02-271-0/+14
| | | | | | | | The channel refactor introduced a regression where we were not honoring the log options passed when enabling the channel. Fix that and add a test. llvm-svn: 296329
* Log: Fix race in accessing the stream variablePavel Labath2017-02-211-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The code was attempting to copy the shared pointer member in order to guarantee atomicity, but this is not enough. Instead, protect the pointer with a proper read-write mutex. This bug was present here for a long time, but my recent refactors must have altered the timings slightly, such that now this fails fairly often when running the tests: the test runner runs the "log disable" command just as the thread monitoring the lldb-server child is about to report that the server has exited. I add a test case for this. It's not possible to reproduce the race deterministically in normal circumstances, but I have verified that before the fix, the test failed when run under tsan, and was running fine afterwards. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30168 llvm-svn: 295712
OpenPOWER on IntegriCloud