summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Process/gdb-remote/GDBRemoteTestUtils.h
Commit message (Collapse)AuthorAgeFilesLines
* Simplify the gdb-remote unit testsPavel Labath2017-06-221-3/+4
| | | | | | | | | Instead of every test creating a client-server combo, do that in the SetUp method of the test fixture. This also means that we can rely on gtest to not run the test if the SetUp method fails and delete the if(HasFailure) calls. llvm-svn: 306013
* Attempt to fix freebsd build after r287864Pavel Labath2016-11-241-3/+2
| | | | | | | | | | the chrono library there uses long long as the underlying chrono type, but defines int64_t as long (or the other way around, I am not sure). In any case, this caused the implicit conversion to not trigger. This should address that. Also fix up the relevant unit test. llvm-svn: 287867
* Fix unittest compilation on windowsPavel Labath2016-09-071-1/+2
| | | | | | | | After the reformat, the unittests do not compile due to missing due to redefinition errors between PosixApi.h and ucrt/direct.h. This is a bit of a shot in the dark, as I have not tested it on windows, but I am restoring the original include order, so it should hopefully fix it. llvm-svn: 280793
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-34/+27
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Convert some functions to use StringRef instead of c_str, lenZachary Turner2016-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | This started as an effort to change StringExtractor to store a StringRef internally instead of a std::string. I got that working locally with just 1 test failure which I was unable to figure out the cause of. But it was also a massive changelist due to a trickle down effect of changes. So I'm starting over, using what I learned from the first time to tackle smaller, more isolated changes hopefully leading up to a full conversion by the end. At first the changes (such as in this CL) will seem mostly a matter of preference and pointless otherwise. However, there are some places in my larger CL where using StringRef turned 20+ lines of code into 2, drastically simplifying logic. Hopefully once these go in they will illustrate some of the benefits of thinking in terms of StringRef. llvm-svn: 279917
* Fix unittest compilation error in r278915Pavel Labath2016-08-171-0/+1
| | | | llvm-svn: 278918
* Move packet construction from GDBRemoteRegisterContext go the communication ↵Pavel Labath2016-08-171-0/+57
class Summary: When saving/restoring registers the GDBRemoteRegisterContext class was manually constructing the register save/restore packets. This creates appropriate helper functions in GDBRemoteCommunicationClient, and switches the class to use those. It also removes what a duplicate packet send in some of those functions, a thing that I can only attribute to a bad merge artefact. I also add a test framework for testing gdb-remote client functionality and add tests for the new functions I introduced. I'd like to be able to test the register context changes in isolation as well, but currently there doesn't seem to be a way to reasonably construct a standalone register context object, so we'll have to rely on the end-to-end tests to verify that. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23553 llvm-svn: 278915
OpenPOWER on IntegriCloud