summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Reapply "Refactor log channel registration mechanism"Pavel Labath2017-02-171-0/+113
| | | | | | | | | Changes wrt. previous version: - add #include <atomic>: fix build on windows - add extra {} around the string literals used to initialize llvm::StringLiteral: fix gcc build llvm-svn: 295442
* Fix breakage caused by r295368Pavel Labath2017-02-172-20/+0
| | | | | | | Also move the ErrorTest into the Utility package, to follow the class it is testing. llvm-svn: 295436
* Revert "Refactor log channel registration mechanism"Pavel Labath2017-02-151-113/+0
| | | | | | | The change breaks on Windows and NetBSD bots. Revert while I investigate. llvm-svn: 295201
* Refactor log channel registration mechanismPavel Labath2017-02-151-0/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have two log channel registration mechanisms. One uses a set of function pointers and the other one is based on the PluginManager. The PluginManager dependency is unfortunate, as logging is also used in lldb-server, and the PluginManager pulls in a lot of classes which are not used in lldb-server. Both approach have the problem that they leave too much to do for the user, and so the individual log channels end up reimplementing command line argument parsing, category listing, etc. Here, I replace the PluginManager-based approach with a one. The new API is more declarative, so the user only needs to specify the list of list of channels, their descriptions, etc., and all the common tasks like enabling/disabling categories are hadled by common code. I migrate the LogChannelDWARF (only user of the PluginManager method) to the new API. In the follow-up commits I'll replace the other channels with something similar. Reviewers: clayborg, zturner, beanz Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D29895 llvm-svn: 295190
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+1
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Convert Log class to llvm streamsPavel Labath2017-02-103-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This converts LLDB's logging to use llvm streams instead of lldb_private::Stream and friends. The changes are mostly straight-forward and amount to s/lldb_private::Stream/llvm::raw_ostream. The part worth calling out is the rewrite of the StreamCallback class. Previously this class contained a per-thread buffer of data written. I assume this had something to do with it trying to make sure each log line is delivered as a single event, instead of multiple (possibly interleaved) events. However, this is no longer relevant as the Log class already writes things to a temporary buffer and then delivers the message as a single "write", so I have just removed the code in question. Reviewers: zturner, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D29615 llvm-svn: 294736
* Move classes from Core -> Utility.Zachary Turner2017-02-025-6/+6
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* [CMake] Update unit tests with accurate dependenciesChris Bieneman2017-02-011-0/+6
| | | | | | This is extending the updates from r293696 to the LLDB unit tests. llvm-svn: 293821
* Add format_provider for lldb::StateTypePavel Labath2017-01-242-0/+22
| | | | | | | | | | Reviewers: clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D29036 llvm-svn: 292920
* Fix new Log unit testPavel Labath2017-01-181-1/+1
| | | | | | | the test was flaky because I specified the format string for the process id incorrectly. This should fix it. llvm-svn: 292414
* Fix windows build for previous commitPavel Labath2017-01-181-1/+2
| | | | | | We get an error about a redefinition of getcwd(). This seems to fix it. llvm-svn: 292364
* Add a more succinct logging syntaxPavel Labath2017-01-182-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds the LLDB_LOG macro, which enables one to write more succinct log statements. if (log) log->Printf("log something: %d", var); becomes LLDB_LOG(log, "log something: {0}, var); The macro still internally does the "if(log)" dance, so the arguments are only evaluated if logging is enabled, meaning it has the same overhead as the previous syntax. Additionally, the log statements will be automatically prefixed with the file and function generating the log (if the corresponding new argument to the "log enable" command is enabled), so one does not need to manually specify this in the log statement. It also uses the new llvm formatv syntax, which means we don't have to worry about PRIx64 macros and similar, and we can log complex object (llvm::StringRef, lldb_private::Error, ...) more easily. Differential Revision: https://reviews.llvm.org/D27459 llvm-svn: 292360
* Add format_provider for the Error classPavel Labath2017-01-122-0/+20
| | | | | | | | | | | | | | | Summary: The formatter supports the same options as the string-like classes, i.e. the ability to truncate the displayed string. I don't anticipate it would be much used, but it seems consistent. Reviewers: zturner, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D28519 llvm-svn: 291759
* Use Timeout<> in the Listener classPavel Labath2016-11-302-38/+39
| | | | | | | | | | | | | | | | | | | | Summary: Communication classes use the Timeout<> class to specify the timeout. Listener class was converted to chrono some time ago, but it used a different meaning for a timeout of zero (Listener: infinite wait, Communication: no wait). Instead, Listener provided separate functions which performed a non-blocking event read. This converts the Listener class to the new Timeout class, to improve consistency. It also allows us to get merge the different GetNextEvent*** and WaitForEvent*** functions into one. No functional change intended. Reviewers: jingham, clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D27136 llvm-svn: 288238
* Add a couple of tests for the Listener classPavel Labath2016-11-242-0/+115
| | | | | | | I'm considering doing some refactor there, so I am adding these to guard the current behavior. llvm-svn: 287896
* Fix some unit test compilation failures.Zachary Turner2016-11-161-1/+1
| | | | llvm-svn: 287158
* Fix Timer unit testPavel Labath2016-11-031-11/+8
| | | | | | | | I did not take into account that the output of the Dump function will be non-deterministic. Fix that by increasing of the times, this also makes the test check that the dump function sorts the output. llvm-svn: 285892
* Refactor Timer classPavel Labath2016-11-032-0/+76
| | | | | | | | | | | | | | | | | | | | | | Summary: While removing TimeValue from this class I noticed a lot of room for small simplifications here. Main are: - instead of complicated start-stop dances to compute own time, each Timer just starts the timer once, and keeps track of the durations of child timers. Then the own time can be computed at the end by subtracting the two values. - remove double accounting in TimerStack - the stack object already knows the number of timers. The interface does not lend itself well to unit testing, but I have added a couple of tests which can (and did) catch any obvious errors. Reviewers: tberghammer, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D26243 llvm-svn: 285890
* unittests: Specify types in a bunch of unittest EXPECT'sJustin Bogner2016-10-171-21/+21
| | | | | | | The EXPECT and ASSERT macros in gtest don't do the usual arithmetic conversions. Specify types in several of them to fix -Werror. llvm-svn: 284405
* Fix TestBreakpointSerialization on windowsPavel Labath2016-09-222-0/+33
| | | | | | | | | The test exposed a bug in the StructuredData Serialization code, which did not escape the backslash properly. This manifested itself as windows breakpoint serialization roundtrip test not succeeding (as windows paths included backslashes). llvm-svn: 282167
* Allow ArchSpec to take a StringRef.Zachary Turner2016-09-151-0/+41
| | | | llvm-svn: 281662
* Convert ArchSpec::ParseMachOCPUDashSubtypeTriple to use StringRef.Zachary Turner2016-09-151-10/+2
| | | | | | | | | | | | | This makes the code easier to grok, and since this is a very low level function it also is very helpful to have this take a StringRef since it means anyone higher up the chain who has a StringRef would have to first convert it to a null-terminated string. This way it can work equally well with StringRefs or const char*'s, which will enable the conversion of higher up functions to StringRef. Tested on Windows, Linux, and OSX and saw no regressions. llvm-svn: 281642
* Add some unit tests for ArchSpec.Zachary Turner2016-09-132-0/+104
| | | | | | | | | | | | I'm was trying to do some cleanup and code modernization and in doing so I needed to change ParseMachCPUDashSubtypeTriple to take a StringRef. To ensure I don't break anything, I'm adding some unit tests for this function. As a side benefit, this also expands test coverage of this function to all platforms, since in general this code would rarely be exercised on non Mac platforms, and never in the test suite. llvm-svn: 281387
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-063-174/+176
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Reapply "Make Scalar::GetValue more consistent"Pavel Labath2016-09-021-0/+37
| | | | | | | | this is a resubmission of r280476. The problem with the original commit was that it was printing out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and add a unit test covering that case. llvm-svn: 280480
* Revert "Make Scalar::GetValue more consistent"Pavel Labath2016-09-021-29/+0
| | | | | | | This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit breakage, and I did not run the 32-bit test suite before submitting, oops. llvm-svn: 280478
* Make Scalar::GetValue more consistentPavel Labath2016-09-021-0/+29
| | | | | | | | | | | | | | | | | | | | | | | Summary: It seems the original intention of the function was printing signed values in decimal format, and unsigned values in hex (without the leading "0x"). However, signed and unsigned long were exchanged, which lead to amusing test failures in TestMemoryFind.py. Instead of just switching the two, I think we should just print everything in decimal here, as the current behaviour is very confusing (especially when one does not request printing of types). Nothing seems to depend on this behaviour except and we already have a way for the user to request the format he wants when printing values for most commands (which presumably does not go through this function). I also add a unit tests for the function in question. Reviewers: clayborg, granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24126 llvm-svn: 280476
* Fix a race in Broadcaster/Listener interactionPavel Labath2016-08-152-0/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The following problem was occuring: - broadcaster B had two listeners: L1 and L2 (thread T1) - (T1) B has started to broadcast an event, it has locked a shared_ptr to L1 (in ListenerIterator()) - on another thread T2 the penultimate reference to L1 was destroyed (the transient object in B is now the last reference) - (T2) the last reference to L2 was destroyed as well - (T1) B has finished broadcasting the event to L1 and destroyed the last shared_ptr - (T1) this triggered the destructor, which called into B->RemoveListener() - (T1) all pointers in the m_listeners list were now stale, so RemoveListener emptied the list - (T1) Eventually control returned to the ListenerIterator() for doing broadcasting, which was still in the middle of iterating through the list - (T1) Only now, it was holding onto a dangling iterator. BOOM. I fix this issue by making sure nothing can interfere with the iterate-and-remove-expired-pointers loop, by moving this logic into a single function, which first locks (or clears) the whole list and then returns the list of valid and locked Listeners for further processing. Instead of std::list I use an llvm::SmallVector which should hopefully offset the fact that we create a copy of the list for the common case where we have only a few listeners (no heap allocations). A slight difference in behaviour is that now RemoveListener does not remove an element from the list -- it only sets it's mask to 0, which means it will be removed during the next iteration of GetListeners(). This is purely an implementation detail and it should not be externally noticable. I was not able to reproduce this bug reliably without inserting sleep statements into the code, so I do not add a test for it. Instead, I add some unit tests for the functions that I do modify. Reviewers: clayborg, jingham Subscribers: tberghammer, lldb-commits Differential Revision: https://reviews.llvm.org/D23406 llvm-svn: 278664
* Fix DataExtractor::PeekData for zero length peeksPavel Labath2016-07-261-3/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: The function was returning the null pointer for peeks of size zero, which seems like a sensible thing to do, but is actually pretty easy to get bitten by that if you are extracting a variable length field which happens to be of zero length and then doing pointer arithmetic on that (which SymbolFileDWARF does, and ended up crashing in case of empty DW_AT_location). This changes the function to return a null pointer only when it gets queried for data which is outside of the range of the extractor, which is more c++-y, as one can still do reasonable things with pointers to data of size zero (think, end() iterators). I also add a test and fix some signedness warnings in the existing data extractor tests. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D22755 llvm-svn: 276734
* Avoid an assertion failure when a bit field is extracted from a value of the ↵Bryan Chan2016-05-191-0/+24
| | | | | | | | | | | | | | same size. Summary: One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures. Reviewers: uweigand, labath Subscribers: labath, lldb-commits Differential Revision: http://reviews.llvm.org/D20355 llvm-svn: 270062
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-151-0/+49
| | | | | | | | | | | | | Recommit modified version of r266311 including build bot regression fix. This differs from the original r266311 by: - Fixing Scalar::Promote to correctly zero- or sign-extend value depending on signedness of the *source* type, not the target type. - Omitting a few stand-alone fixes that were already committed separately. llvm-svn: 266422
* Revert r266311 - Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-49/+0
| | | | | | Try to get 32-bit build bots running again. llvm-svn: 266341
* Handle bit fields on big-endian systems correctlyUlrich Weigand2016-04-142-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield routines assume the incoming "bitfield_bit_offset" parameter uses little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to a bitfield whose least-significant bit coincides with the least- significant bit of the surrounding integer. On many big-endian systems, however, the big-endian bit numbering is used for bit fields. Here, a bitfield_bit_offset 0 refers to a bitfield whose most-significant bit conincides with the most- significant bit of the surrounding integer. Now, in principle LLDB could arbitrarily choose which semantics of bitfield_bit_offset to use. However, there are two problems with the current approach: - When parsing DWARF, LLDB decodes bit offsets in little-endian bit numbering on LE systems, but in big-endian bit numbering on BE systems. Passing those offsets later on into the DataExtractor routines gives incorrect results on BE. - In the interim, LLDB's type layer combines byte and bit offsets into a single number. I.e. instead of recording bitfields by specifying the byte offset and byte size of the surrounding integer *plus* the bit offset of the bit field within that field, it simply records a single bit offset number. Now, note that converting from byte offset + bit offset to a single offset value and back is well-defined if we either use little-endian byte order *and* little-endian bit numbering, or use big-endian byte order *and* big-endian bit numbering. Any other combination will yield incorrect results. Therefore, the simplest approach would seem to be to always use the bit numbering that matches the system byte order. This makes storing a single bit offset valid, and makes the existing DWARF code correct. The only place to fix is to teach DataExtractor to use big-endian bit numbering on big endian systems. However, there is only additional caveat: we also get bit offsets from LLDB synthetic bitfields. While the exact semantics of those doesn't seem to be well-defined, from test cases it appears that the intent was for the user-provided synthetic bitfield offset to always use little-endian bit numbering. Therefore, on a big-endian system we now have to convert those to big-endian bit numbering to remain consistent. Differential Revision: http://reviews.llvm.org/D18982 llvm-svn: 266312
* Fix usage of APInt.getRawData for big-endian systemsUlrich Weigand2016-04-141-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scalar implementation and a few other places in LLDB directly access the internal implementation of APInt values using the getRawData method. Unfortunately, pretty much all of these places do not handle big-endian systems correctly. While on little-endian machines, the pointer returned by getRawData can simply be used as a pointer to the integer value in its natural format, no matter what size, this is not true on big-endian systems: getRawData actually points to an array of type uint64_t, with the first element of the array always containing the least-significant word of the integer. This means that if the bitsize of that integer is smaller than 64, we need to add an offset to the pointer returned by getRawData in order to access the value in its natural type, and if the bitsize is *larger* than 64, we actually have to swap the constituent words before we can access the value in its natural type. This patch fixes every incorrect use of getRawData in the code base. For the most part, this is done by simply removing uses of getRawData in the first place, and using other APInt member functions to operate on the integer data. This can be done in many member functions of Scalar itself, as well as in Symbol/Type.h and in IRInterpreter::Interpret. For the latter, I've had to add a Scalar::MakeUnsigned routine to parallel the existing Scalar::MakeSigned, e.g. in order to implement an unsigned divide. The Scalar::RawUInt, Scalar::RawULong, and Scalar::RawULongLong were already unused and can be simply removed. I've also removed the Scalar::GetRawBits64 function and its few users. The one remaining user of getRawData in Scalar.cpp is GetBytes. I've implemented all the cases described above to correctly implement access to the underlying integer data on big-endian systems. GetData now simply calls GetBytes instead of reimplementing its contents. Finally, two places in the clang interface code were also accessing APInt.getRawData in order to actually construct a byte representation of an integer. I've changed those to make use of a Scalar instead, to avoid having to re-implement the logic there. The patch also adds a couple of unit tests verifying correct operation of the GetBytes routine as well as the conversion routines. Those tests actually exposed more problems in the Scalar code: the SetValueFromData routine didn't work correctly for 128- and 256-bit data types, and the SChar routine should have an explicit "signed char" return type to work correctly on platforms where char defaults to unsigned. Differential Revision: http://reviews.llvm.org/D18981 llvm-svn: 266311
* Change `CoreTests` to LLDBCoreTests to avoid name clash.Zachary Turner2016-02-091-1/+1
| | | | | | | lld was already using a target named CoreTests so CMake was erroring due to this conflict. llvm-svn: 260326
* Fix invalid shift operator overload in ScalarPavel Labath2016-02-092-0/+35
Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= (). Reviewers: sagar, tberghammer, labath Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16868 Patch by Marianne Mailhot-Sarrasin llvm-svn: 260239
OpenPOWER on IntegriCloud