summaryrefslogtreecommitdiffstats
path: root/lldb/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* Yet another follow-up to r332111. This also handles the case where anAdrian Prantl2018-05-111-5/+5
| | | | | | | LLDB.framework is built inside the LLDB build directory (but not inside an Xcode installation). llvm-svn: 332126
* Fix a regression in r332111. The LLDB.framework path component is notAdrian Prantl2018-05-111-1/+7
| | | | | | usually the last component. llvm-svn: 332120
* HostInfoMacOSX: Share the clang resource directory with Swift.Adrian Prantl2018-05-112-0/+41
| | | | | | | | | | | | | Inside Xcode and in Xcode toolchains LLDB is always in lockstep with the Swift compiler, so it can reuse its Clang resource directory. This allows LLDB and the Swift compiler to share the same Clang module cache. rdar://problem/40039633 Differential Revision: https://reviews.llvm.org/D46736 llvm-svn: 332111
* Remove custom path manipulation functions from FileSpecPavel Labath2018-05-111-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: now that llvm supports host-agnostic path manipulation functions (and most of their kinks have been ironed out), we can remove our copies of the path parsing functions in favour of the llvm ones. This should be NFC except for the slight difference in handling of the "//" path, which is now normalized to "/" (this only applies to the literal "//" path; "//net" and friends still get to keep the two slashes). Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46687 llvm-svn: 332088
* CPlusPlusLanguage: Add unit tests for the FindAlternateFunctionManglings methodPavel Labath2018-05-101-2/+23
| | | | | | | | I was considering modifying this function, so I wrote some tests to make sure I don't regress its behavior. I am not sure if I will actually proceed with the modifications, but the tests seem useful nonetheless. llvm-svn: 331966
* [cmake, unittests] Fix the CMake file for the LLDB unittests to support ↵Stella Stamenova2018-05-091-2/+2
| | | | | | | | | | | | | | | | multiple configurations Summary: The current setup for the unit tests only works correctly when the generator does not support multiple configurations. When the generator supports multiple configurations, the inputs are not copied to the correct per-configuration directory. This change sets up the build to copy the inputs in each configuration directory. Reviewers: labath, asmith, zturner Reviewed By: labath Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46642 llvm-svn: 331914
* Modernize and clean-up the Predicate classPavel Labath2018-05-092-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The comments on this class were out of date with the implementation, and the implementation itself was inconsistent with our usage of the Timeout class (I started converting everything to use this class back in D27136, but I missed this one). I avoid duplicating the waiting logic by introducing a templated WaitFor function, and make other functions delegate to that. This function can be also used as a replacement for the unused WaitForBitToBeSet functions I removed, if it turns out to be necessary. As this changes the meaning of a "zero" timeout, I tracked down all the callers of these functions and updated them accordingly. Propagating the changes to all the callers of RunShellCommand was a bit too much for this patch, so I stopped there and will continue that in a follow-up patch. I also add some basic unittests for the functions I modified. Reviewers: jingham, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D46580 llvm-svn: 331880
* Fix gdb-remote qMemoryRegionInfo unit tests for xml-enabled buildsPavel Labath2018-05-021-8/+26
| | | | | | | | | | | | | | | | | In case we are building with xml enabled, the GetMemoryRegionInfo function will send extra packets to query te extended memory map, which the tests were not expecting. Add an expectation for this to the test. Right now, it's just a basic one which pretends we don't support the extension, however, it would be also interesting the add a test which verifies the extension-enabled case. I also noticed that the test does a pretty lousy job of validating the returned memory region info, so I add a couple of extra assertions to improve that. llvm-svn: 331374
* llgs tests: Use noack-mode for communication to avoid pr37294Pavel Labath2018-04-302-2/+16
| | | | llvm-svn: 331180
* Always normalize FileSpec paths.Greg Clayton2018-04-271-57/+25
| | | | | | | | Always normalizing lldb_private::FileSpec paths will help us get a consistent results from comparisons when setting breakpoints and when looking for source files. This also removes a lot of complexity from the comparison routines. Modified the DWARF line table parser to use the normalized compile unit directory if needed. Differential Revision: https://reviews.llvm.org/D45977 llvm-svn: 331049
* llgs-tests: Increase packet time outPavel Labath2018-04-231-0/+1
| | | | | | | | | | | | The default packet timeout of 1 second is a bit too small for these tests, particularly as they are working in ack-mode, which means they need to fit twice as many packets into the timeslot. This does not seem to be a problem on the bots, but for some people these tests are timing out regularly. I can't be sure increasing this will solve their problem, but this does seem like a likely culprit. llvm-svn: 330578
* Move FileSpecTest to UtilityPavel Labath2018-04-203-7/+7
| | | | | | | FileSpec class was moved to the Utility module a while ago, but the test file was left behind. This corrects that. llvm-svn: 330405
* Fix narrowing warning by appending `f` to literal constant.Adrian McCarthy2018-04-191-1/+1
| | | | llvm-svn: 330354
* Move Args.cpp from Interpreter to UtilityPavel Labath2018-04-175-5/+7
| | | | | | | | | | | | | | | | | | | | | Summary: The Args class is used in plenty of places besides the command interpreter (e.g., anything requiring an argc+argv combo, such as when launching a process), so it needs to be in a lower layer. Now that the class has no external dependencies, it can be moved down to the Utility module. This removes the last (direct) dependency from the Host module to Interpreter, so I remove the Interpreter module from Host's dependency list. Reviewers: zturner, jingham, davide Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D45480 llvm-svn: 330200
* llgs: Send "rich" errors in response to vAttach packetsPavel Labath2018-04-112-7/+25
| | | | | | | | | | | | | | | | | There are plenty of ways attaching can go wrong. Having the server report the exact error means we can give better feedback to the user. (This patch does not do the second part, it only makes sure the information is sent from the server.) Triggering all possible error conditions in a test would prove challenging, but there is one error that is very easy to reproduce (attempting to attach while debugging), so I write a test based on that. The test immediately exposed a bug where the m_send_error_strings field was being used uninitialized (so it was sometimes true from the get-go), so I fix that as well. llvm-svn: 329803
* Move Args::StringTo*** functions to a new OptionArgParser classPavel Labath2018-04-103-89/+122
| | | | | | | | | | | | | | | | Summary: The idea behind this is to move the functionality which depend on other lldb classes into a separate class. This way, the Args class can be turned into a lightweight arc+argv wrapper and moved into the lower lldb layers. Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44306 llvm-svn: 329677
* [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
* gdb-remote: Fix checksum verification for messages with escape charsPavel Labath2018-03-283-6/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had a mismatch in the checksum computation between the sender and receiver. The sender computed the payload checksum using the wire encoding of the packet, while the receiver did this after expanding un-escaping and expanding run-length-encoded sequences. This resulted in communication breakdown if packets using these feature were sent in the ack mode. Normally, this did not cause any issues since the only packet we send in the ack-mode is the QStartNoAckMode packet, but I ran into this when debugging the lldb-server tests which (for better or worse) don't use this mode. According to the gdb-remote documentation "The two-digit checksum is computed as the modulo 256 sum of all characters between the leading ‘$’ and the trailing ‘#’", it seems that our sender is doing the right thing here. Therefore, I fix the receiver the match the sender behavior and add a test. With this bug fixed, we can see that lldb-server is sending a stop-reply after receiving the "k" in the same way as debugserver does (but we weren't detecting this because at that point the connection was dead already). I fix that expectation as well. Reviewers: clayborg, jasonmolenda Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D44922 llvm-svn: 328693
* [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
* llgs-tests: use the auto-parsing form of SendMessage for sending the ↵Pavel Labath2018-03-042-11/+8
| | | | | | continue packets llvm-svn: 326671
* [LLDB] Initial version of PPC64 InstEmulationPavel Labath2018-02-276-17/+293
| | | | | | | | | | | | | | | Summary: Supports common prologue/epilogue instructions. Reviewers: clayborg, labath Reviewed By: clayborg, labath Subscribers: davide, anajuliapc, alexandreyy, lbianc, nemanjai, mgorny, kbarton Differential Revision: https://reviews.llvm.org/D43345 Author: Leandro Lupori <leandro.lupori@gmail.com> llvm-svn: 326224
* [unittests] Disable lldb-server tests if an external debug server is in useVedant Kumar2018-02-241-1/+6
| | | | | | | | | | | | The lldb-server unit tests don't test the right thing when the debug server in use is copied from somewhere else. This can lead to spurious test failures. Disable these unit tests when an external debug server is in use. Fixes llvm.org/PR36494. llvm-svn: 326001
* Fix a compiler warning in ModuleCacheTest.cpp, NFCVedant Kumar2018-02-231-2/+2
| | | | llvm-svn: 325974
* [Utility] Simplify and generalize the CleanUp helper, NFCVedant Kumar2018-02-232-0/+48
| | | | | | | | | | | | | | | | | | Removing the template arguments and most of the mutating methods from CleanUp makes it easier to understand and reuse. In its present state, CleanUp would be too cumbersome to adapt to cases where multiple objects need to be released. Take for example this change in swift-lldb: https://github.com/apple/swift-lldb/pull/334/files#diff-6f474df750f75c8ba675f2a8408a5629R219 This change is simple to express with the new CleanUp, but not so simple with the old version. Differential Revision: https://reviews.llvm.org/D43662 llvm-svn: 325964
* llgs-tests: Fix r325511 for debugserverPavel Labath2018-02-212-3/+13
| | | | | | | Debugserver sends the thread-pcs field with leading zeroes omitted. Teach parseRegisterValue to pad these as necessary. llvm-svn: 325701
* Fix TestStopReplyContainsThreadPcs on 32-bit x86 (pr36013)Pavel Labath2018-02-195-103/+166
| | | | | | | | | | | | | | | | | Summary: The issue was that we were parsing the registers into 64-bit integers and the calling swapByteOrder without regard for the actual size of the register. This switches the test to use the RegisterValue class which tracks the register size, and knows how to initialize itself from a piece of memory (so we don't need to swap byte order ourselves). Reviewers: eugene, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D43376 llvm-svn: 325511
* [cmake] Darwin: Copy in the system debugserver if neededVedant Kumar2018-02-131-1/+1
| | | | | | | This makes the built debugger functional on Darwin when compiling without code signing (as documented in docs/code-signing.txt). llvm-svn: 325068
* llgs-test: Parse and store register info recieved from lldb-serverPavel Labath2018-02-095-41/+130
| | | | | | | | | | | | | | | | | | | | Summary: Right now the test client is not parsing register values correctly, which is manifesting itself in one test failing on 32-bit architectures (pr36013). This parses the information from the qRegisterInfo packets and stores it in the client, which will enable fixing the parsing in a follow up commit. I am also adding a new templated SendMessage overload, which enables one to send a message get a parsed response in a single call. Reviewers: eugene, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D43076 llvm-svn: 324722
* More correct handling of error cases C++ name parserEugene Zemtsov2018-02-061-0/+2
| | | | | | | | | | Now incorrect type argument that looks like T<A><B> doesn't cause an assert, but just a parsing error. Bug: 36224 Differential Revision: https://reviews.llvm.org/D42939 llvm-svn: 324380
* Add a comment explaining how the input for ↵Pavel Labath2018-02-052-0/+25
| | | | | | | | | | | | | GetModuleSpecifications_EarlySectionHeaders was generated Davide pointed out this would be useful if the file ever needs to be regenerated (and I certainly agree). I also replace the test binary with a slightly smaller one -- I intended to do this in the original commit, but I forgot to add it to the patch as I was juggling several things at the same time. llvm-svn: 324256
* Fix parsing of object files with "early" section headersPavel Labath2018-02-053-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
* Add LLDB_LOG_ERROR macroPavel Labath2018-01-301-0/+17
| | | | | | | | | | | | | | | | Summary: The difference between this and regular LLDB_LOG is that this one clears the error object unconditionally. This was inspired by the ObjectFileELF bug (r322664), where the error object was being cleared only if logging was enabled. Reviewers: davide, zturner, jingham, clayborg Subscribers: lldb-commits, emaste Differential Revision: https://reviews.llvm.org/D42182 llvm-svn: 323753
* Remove ObjectFile usage from HostLinux::GetProcessInfoPavel Labath2018-01-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ObjectFile class was used to determine the architecture of a running process by inspecting it's main executable. There were two issues with this: - it's in the wrong layer - the call can be very expensive (it can end up computing the crc of the whole file). Since the process is running on the host, ideally we would be able to just query the data straight from the OS like darwin does, but there doesn't seem to be a reasonable way to do that. So, this fixes the layering issue by using the llvm object library to inspect the file. Since we know the process is already running on the host, we just need to peek at a few bytes of the elf header to determine whether it's 32- or 64-bit (which should make this faster as well). Pretty much the same logic was implemented in NativeProcessProtocol::ResolveProcessArchitecture, so I delete this logic and replace calls with GetProcessInfo. Reviewers: eugene, krytarowski Subscribers: mgorny, hintonda, lldb-commits Differential Revision: https://reviews.llvm.org/D42488 llvm-svn: 323637
* Fix memory leak in TestClangASTContext.TestRecordHasFieldsRaphael Isemann2018-01-221-0/+5
| | | | | | | | | | Summary: We can't use unique_ptr's here because we use those variables as `out` parameters to some functions. Discovered by the memory sanitizer. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D42386 llvm-svn: 323138
* Revert "[SymbolFilePDB] Fix null array access when parsing the type of a ↵Pavel Labath2018-01-222-10/+1
| | | | | | | | | | function without any arguments, i.e. 'int main()' and add support to test it" This reverts commit r322995, as it breaks lldb-Unit::SymbolFilePDBTests.TestTypedefs <http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/7715>. llvm-svn: 323102
* Fix memory leaks in MinidumpParserTestRaphael Isemann2018-01-221-6/+6
| | | | | | | | | | | | | | Summary: We never delete the allocated RegisterContext objects, causing those tests to fail with enabled memory sanitizer. Reviewers: dvlahovski, zturner Reviewed By: zturner Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D42347 llvm-svn: 323085
* 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
* Fix memory leaks in TestArm64InstEmulationRaphael Isemann2018-01-221-10/+10
| | | | | | | | | | | | | | Summary: We never delete the created instances, so those test fail with the memory sanitizer. Reviewers: jasonmolenda Reviewed By: jasonmolenda Subscribers: aemerson, javed.absar, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D42336 llvm-svn: 323076
* [SymbolFilePDB] Fix null array access when parsing the type of a function ↵Aaron Smith2018-01-192-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | without any arguments, i.e. 'int main()' and add support to test it Summary: - Fix a null array access bug. This happens when creating the lldb type for a function that has no argument. - Implement SymbolFilePDB::ParseTypes method. Using `lldb-test symbols` will show all supported types in the target. - Create lldb types for variadic function, PDBSymbolTypePointer, PDBSymbolTypeBuiltin - The underlying builtin type for PDBSymbolTypeEnum is always `Int`, correct it with the very first enumerator's encoding if any. This is more accurate when the underlying type is not signed or another integer type. - Fix a bug when the compiler type is not created based on PDB_BuiltinType. For example, basic type `long` is of same width as `int` in a 32-bit target, and the compiler type of former one will be represented by the one generated for latter if using the default method. Introduce a static function GetBuiltinTypeForPDBEncodingAndBitSize to correct this issue. - Basic type `long double` and `double` have the same bit size in MSVC and there is no information in a PDB to distinguish them. The compiler type of the former one is represented by the latter's. - There is no line informaton about typedef, enum etc in a PDB and the source and line information for them are not shown. - There is no information about scoped enumeration. The compiler type is represented as an unscoped one. Reviewers: zturner, lldb-commits, davide, asmith Reviewed By: zturner, asmith Subscribers: llvm-commits, davide Differential Revision: https://reviews.llvm.org/D41427 llvm-svn: 322995
* Simplify some LogTest testsPavel Labath2018-01-171-78/+90
| | | | | | | | | | | This removes boilerplate for setting up a log channel and capturing the output from some of the tests. I do this by moving the setup code into a test fixture and adding a logAndTakeOutput utility function to log some string and then retrieve it from the log. I also use some googlemock goodies to simplify a couple of assertions. llvm-svn: 322653
* Handle O reply packets during qRcmdPavel Labath2018-01-101-0/+20
| | | | | | | | | | | | | | | | | | | | Summary: Gdb servers like openocd may send many $O reply packets for the client to output during a qRcmd command sequence. Currently, lldb interprets the first O packet as an unexpected response. Besides generating no output, this causes lldb to get out of sync with future commands because it continues reading O packets from the first command as response to subsequent commands. This patch handles any O packets during an qRcmd, treating the first non-O packet as the true response. Preliminary discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013078.html Reviewers: clayborg Reviewed By: clayborg Subscribers: labath, lldb-commits Differential Revision: https://reviews.llvm.org/D41745 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 322190
* Add Utility/Environment class for handling... environmentsPavel Labath2018-01-105-96/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was some confusion in the code about how to represent process environment. Most of the code (ab)used the Args class for this purpose, but some of it used a more basic StringList class instead. In either case, the fact that the underlying abstraction did not provide primitive operations for the typical environment operations meant that even a simple operation like checking for an environment variable value was several lines of code. This patch adds a separate Environment class, which is essentialy a llvm::StringMap<std::string> in disguise. To standard StringMap functionality, it adds a couple of new functions, which are specific to the environment use case: - (most important) envp conversion for passing into execve() and likes. Instead of trying to maintain a constantly up-to-date envp view, it provides a function which creates a envp view on demand, with the expectation that this will be called as the very last thing before handing the value to the system function. - insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value) pair and inserts it into the environment map. - compose(value_type KeyValue) - takes a map entry and converts in back into "KEY=VALUE" representation. With this interface most of the environment-manipulating code becomes one-liners. The only tricky part was maintaining compatibility in SBLaunchInfo, which expects that the environment entries are accessible by index and that the returned const char* is backed by the launch info object (random access into maps is hard and the map stores the entry in a deconstructed form, so we cannot just return a .c_str() value). To solve this, I have the SBLaunchInfo convert the environment into the "envp" form, and use it to answer the environment queries. Extra code is added to make sure the envp version is always in sync. (This also improves the layering situation as Args was in the Interpreter module whereas Environment is in Utility.) Reviewers: zturner, davide, jingham, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41359 llvm-svn: 322174
* [ArchSpec] Add a unittest to complement the change in r321856.Davide Italiano2018-01-051-0/+19
| | | | | | <rdar://problem/35778442> llvm-svn: 321879
* Update failing PDB unit tests that are searching for symbols by regexAaron Smith2017-12-281-12/+8
| | | | | | | | | | | | Summary: D41086 fixed an exception in FindTypes()/FindTypesByRegex() and caused two lldb unit test to fail. This change updates the unit tests to pass again. Reviewers: zturner, lldb-commits, labath, clayborg, asmith Reviewed By: asmith Differential Revision: https://reviews.llvm.org/D41550 llvm-svn: 321511
* debugserver: Propagate environment in launch-mode (pr35671)Pavel Labath2017-12-224-14/+43
| | | | | | | | | | | | | | | | | | Summary: Make sure we propagate environment when starting debugserver with a pre-loaded inferior. AFAIK, RNBRunLoopLaunchInferior is only called in pre-loaded inferior scenario, so we can just pick up the debugserver environment instead of trying to construct an envp from the (empty) context. This makes debugserver pass an test added for an equivalent lldb-server fix. Reviewers: jasonmolenda, clayborg Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D41352 llvm-svn: 321355
* [lldb] Stop searching for a symbol in a pdb by regexAaron Smith2017-12-221-0/+7
| | | | | | | | | | | | | | | | | Summary: It was possible when searching for a symbol by regex in a pdb that an invalid regex would cause an exception on Windows. This updates the code to avoid throwing an exception. When fixing the exception it was decided there is no reason to search for a symbol in a pdb by regex. To support this, SymbolFilePDB::FindTypes() now only searches for types by name and no longer calls FindTypesByRegEx(). Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: clayborg Differential Revision: https://reviews.llvm.org/D41086 llvm-svn: 321344
* Enable more abilities in SymbolFilePDBAaron Smith2017-12-221-2/+1
| | | | | | | | | | | | | | | | Summary: 1) Finding symbols through --symfile 2) More abilities: Functions, Blocks, GlobalVariables, LocalVariables, VariableTypes Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: clayborg Differential Revision: https://reviews.llvm.org/D41092 llvm-svn: 321327
* Fix regression in jModulesInfo packet handlingPavel Labath2017-12-181-7/+35
| | | | | | | | | | | | | | | | | | | | | | | The recent UUID cleanups exposed a bug in the parsing code for the jModulesInfo response, which was passing wrong value for the second argument to UUID::SetFromStringRef (it passed the length of the string, whereas the correct value should be the number of decoded bytes we expect to receive). This was not picked up by tests, because they test with 16-byte uuids, for which the function happens to do the right thing even if the length does not match (if the length does not match, the function does not update m_num_uuid_bytes member, but that member is already 16 to begin with). I fix that and add a test with 20-byte uuid to catch if this regresses. I have also added more safeguards into the parsing code to fail if we cannot parse the entire uuid field we recieve. While testing the latter part, I noticed that the "negative" jModulesInfo tests were succeeding because we were sending malformed json (and not because the json contents was invalid), so I make those tests a bit more robuts as well. llvm-svn: 320985
* llgs: Propagate the environment when launching the inferior from command linePavel Labath2017-12-185-2/+72
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were failing to propagate the environment when lldb-server was started with a pre-loaded process (e.g.: lldb-server gdbserver -- inferior --inferior_args) This patch makes sure the environment is propagated. Instead of adding a new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to complement SetLaunchArgs and SetLaunchFlags, I replace these with a more generic SetLaunchInfo, which can be used to set any launch-related property. The accompanying test also verifies that the server correctly terminates the connection after sending the exit packet (specifically, that it does not send the exit packet twice). Reviewers: clayborg, eugene Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41070 llvm-svn: 320984
* NPL: Clean up handling of inferior exitPavel Labath2017-12-181-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lldb-server was sending the "exit" packet (W??) twice. This happened because it was handling both the pre-exit (PTRACE_EVENT_EXIT) and post-exit (WIFEXITED) as exit events. We had some code which was trying to detect when we've already sent the exit packet, but this stopped working quite a while ago. This never really caused any problems in practice because the client automatically closes the connection after receiving the first packet, so the only effect of this was some warning messages about extra packets from the lldb-server test suite, which were ignored because they didn't fail the test. The new test suite will be stricter about this, so I fix this issue ignoring the first event. I think this is the correct behavior, as the inferior is not really dead at that point, so it's premature to send the exit packet. There isn't an actual test yet which would verify the exit behavior, but in my next patch I will add a test which will also test this functionality. Reviewers: eugene Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D41069 llvm-svn: 320961
OpenPOWER on IntegriCloud