summaryrefslogtreecommitdiffstats
path: root/lldb/unittests
Commit message (Collapse)AuthorAgeFilesLines
* Fix a no newline at end of file warning.Greg Clayton2016-06-091-1/+1
| | | | llvm-svn: 272284
* Add unit tests for ModuleCachePavel Labath2016-05-254-0/+192
| | | | | | | | | | Reviewers: ovyalov, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20570 llvm-svn: 270684
* 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 SymbolFilePDBTests.cppPavel Labath2016-05-101-14/+15
| | | | llvm-svn: 269057
* Revert "Add a read_full_buffer argument to ConnectionFileDescriptor::Read"Pavel Labath2016-05-034-207/+75
| | | | | | | This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to ConnectionGenericFileWindows). llvm-svn: 268384
* Add a read_full_buffer argument to ConnectionFileDescriptor::ReadPavel Labath2016-05-034-75/+207
| | | | | | | | | | | | | | | | | | | | | Summary: AdbClient was attempting to handle the case where the socket input arrived in pieces, but it was failing to handle the case where the connection was closed before that happened. In this case, it would just spin in an infinite loop calling Connection::Read. (This was also the cause of the spurious timeouts on the darwin->android buildbot. The exact cause of the premature EOF remains to be investigated, but is likely a server bug.) Since this wait-for-a-certain-number-of-bytes seems like a useful functionality to have, I am moving it (with the infinite loop fixed) to the Connection class, and adding an appropriate test for it. Reviewers: clayborg, zturner, ovyalov Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: http://reviews.llvm.org/D19533 llvm-svn: 268380
* Fix compiler warnings in SymbolFilePDBTestsPavel Labath2016-04-271-20/+20
| | | | llvm-svn: 267688
* Add missing file needed for PDB unittests.Zachary Turner2016-04-201-0/+0
| | | | llvm-svn: 266886
* 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
* Initial support for reading type information from PDBs.Zachary Turner2016-04-154-5/+331
| | | | | | | | | | | | | | | | This implements a PDBASTParser and corresponding logic in SymbolFilePDB to do type lookup by name. This is just a first pass and leaves many aspects of type lookup unimplemented, and just focuses on laying the framework. With this patch, you should be able to lookup basic types by name from a PDB. Full class definitions are not completed yet, we will instead just return a forward declaration of the class. Differential Revision: http://reviews.llvm.org/D18848 Reviewed by: Greg Clayton llvm-svn: 266392
* 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
* FileSpec: make matching separator-agnostic againPavel Labath2016-04-141-6/+20
| | | | | | | | | | | | | | | | | | | | | Summary: In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a problem because we would consider paths with different separators as different (which led to unresolved breakpoints for instance). Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I am commenting out the GetDirectory unittests until we figure out the what is the expected behaviour here. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19060 llvm-svn: 266286
* Remove obsolete commentsPavel Labath2016-04-131-2/+0
| | | | llvm-svn: 266196
* Initialize the Python script interpreter lazily (i.e. not at debugger startup)Enrico Granata2016-04-121-0/+1
| | | | | | This time it should also pass the gtests llvm-svn: 266103
* Make FileSpec handling platform-independentPavel Labath2016-04-041-14/+19
| | | | | | | | | | | | | | | | | Summary: Even though FileSpec attempted to handle both kinds of path syntaxes (posix and windows) on both platforms, it relied on the llvm path library to do its work, whose behavior differed on different platforms. This led to subtle differences in FileSpec behavior between platforms. This replaces the pieces of the llvm library with our own implementations. The functions are simply copied from llvm, with #ifdefs replaced by runtime checks for ePathSyntaxWindows. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18689 llvm-svn: 265299
* Add some unit tests for ClangASTContext.Zachary Turner2016-04-013-0/+319
| | | | | | | | | | | In doing so, two bugs were uncovered (and fixed). The first bug is that ClangASTContext::RemoveFastQualifiers() was broken, and was not removing fast qualifiers (or doing anything else for that matter). The second bug is that UnifyAccessSpecifiers treated AS_None asymmetrically, which is probably an edge case, but seems like a bug nonetheless. llvm-svn: 265200
* Fix SocketAddressTest (again)Pavel Labath2016-03-301-1/+2
| | | | | | | On some versions of Windows, the address is returned as "::1", while on others it's "0:0:...:0:1". Accept both versions, as they represent the same address. llvm-svn: 264850
* Fix a bunch of signedness warnings in unittestsPavel Labath2016-03-112-16/+17
| | | | llvm-svn: 263209
* Fix a couple of cornercases in FileSpec + testsPavel Labath2016-03-112-0/+95
| | | | | | | | | | | | | | | | | | | Summary: This fixes a couple of corner cases in FileSpec, related to AppendPathComponent and handling of root directory (/) file spec. I add a bunch of unit tests for the new behavior. Summary of changes: FileSpec("/bar").GetCString(): before "//bar", after "/bar". FileSpec("/").CopyByAppendingPathComponent("bar").GetCString(): before "//bar", after "/bar". FileSpec("C:", ePathSyntaxWindows).CopyByAppendingPathComponent("bar").GetCString(): before "C:/bar", after "C:\bar". Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18044 llvm-svn: 263207
* Add support for reading line tables from PDB files.Zachary Turner2016-03-0212-0/+431
| | | | | | | | | | | | | | | | | | | | | | | | | | PDB is Microsoft's debug information format, and although we cannot yet generate it, we still must be able to consume it. Reason for this is that debug information for system libraries (e.g. kernel32, C Runtime Library, etc) only have debug info in PDB format, so in order to be able to support debugging of system code, we must support it. Currently this code should compile on every platform, but on non-Windows platforms the PDB plugin will return 0 capabilities, meaning that for now PDB is only supported on Windows. This may change in the future, but the API is designed in such a way that this will require few (if any) changes on the LLDB side. In the future we can just flip a switch and everything will work. This patch only adds support for line tables. It does not return information about functions, types, global variables, or anything else. This functionality will be added in a followup patch. Differential Revision: http://reviews.llvm.org/D17363 Reviewed by: Greg Clayton llvm-svn: 262528
* Fix PythonDataObjectsTests for python 2Pavel Labath2016-02-251-2/+1
| | | | | | | | | | | | | | Summary: the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes". Fix the expectation. Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17545 llvm-svn: 261901
* Fix SocketTest on Windows.Zachary Turner2016-02-181-4/+0
| | | | | | Differential Revision: http://reviews.llvm.org/D17106 llvm-svn: 261240
* 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-093-0/+36
| | | | | | | | | | | | | | 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
* Fix sign conversion warnings in LLDB Python unittestsReid Kleckner2016-02-031-19/+18
| | | | llvm-svn: 259689
* Fix an off-by-one in SocketTest::DecodeHostAndPortPavel Labath2016-02-031-1/+11
| | | | | | | 65535 is still a valid port. This should fix the android failures we were getting when we chose to connect over 65535 to the remote lldb-server. llvm-svn: 259638
* Fix swig typemap for SBEvent.Zachary Turner2016-01-251-0/+14
| | | | | | | | | | | This needs to be able to handle bytes, strings, and bytearray objects. In Python 2 this was easy because bytes and strings are the same thing, but in Python 3 the 2 cases need to be handled separately. So as not to mix raw Python C API code with PythonDataObjects code, I've also introduced a PythonByteArray class to PythonDataObjects to make the paradigm used here consistent. llvm-svn: 258741
* added test fixture to EditlineTest gtestTodd Fiala2016-01-221-32/+35
| | | | | | | | | | Primarily a trial test for me to try out the git clang-format integration. Works like a charm! This change adds a gtest fixture for the EditlineTest common setup and teardown code. llvm-svn: 258565
* Introduce a PythonBytes class into PythonDataObjects.Zachary Turner2016-01-111-0/+21
| | | | | | | This class behaves the same as PythonString on Python2, but differently on Python3. Unittests are added as well. llvm-svn: 257397
* Fix a bug in PythonExceptionState and add unittest coverage.Zachary Turner2015-11-131-0/+53
| | | | | | | I forgot to reset the restore flag when calling member function `Acquire`. The newly added unittest should cover this case. llvm-svn: 253002
* Introduce a `PythonExceptionState` class.Zachary Turner2015-11-132-0/+122
| | | | | | | | | | | | This is a helper class which supports a number of features including exception to string formatting with backtrace handling and auto-restore of exception state upon scope exit. Additionally, unit tests are included to verify the feature set of the class. llvm-svn: 252994
* gtest - Make a `PythonTestSuite` base class for setup / teardown.Zachary Turner2015-11-134-17/+74
| | | | | | | | This allows other potential unit test suites (of which one is forthcoming in a subsequent patch) to re-use the same initialization and teardown of the GIL. llvm-svn: 252993
* Create `PythonTuple` and `PythonCallable` wrapper classes.Zachary Turner2015-11-111-11/+132
| | | | | | | | | | | | | | This adds PythonTuple and PythonCallable classes to PythonDataObjects. Additionally, unit tests are provided that exercise this functionality, including invoking manipulating and checking for validity of tuples, and invoking and checking for validity of callables using a variety of different syntaxes. The goal here is to eventually replace the code in python-wrapper.swig that directly uses the Python C API to deal with callables and name resolution with this code that can be more easily tested and debugged. llvm-svn: 252787
* Add a `PythonModule` class, and a root-level method for resolving names.Zachary Turner2015-11-111-0/+60
| | | | llvm-svn: 252765
* Fix build for go parser unittest.Ryan Brown2015-11-031-1/+1
| | | | llvm-svn: 252007
* Create an expression parser for Go.Ryan Brown2015-11-023-0/+254
| | | | | | | | | | | The Go interpreter doesn't JIT or use LLVM, so this also moves all the JIT related code from UserExpression to a new class LLVMUserExpression. Differential Revision: http://reviews.llvm.org/D13073 Fix merge llvm-svn: 251820
* Added real editline tests.Todd Fiala2015-10-301-2/+355
| | | | | | | | | These are two simple tests that make sure single line and multiline content are processed and received by Editline.cpp. Fancier tests to come... llvm-svn: 251681
* Fix a copy-and-paste error on new Editline test cmake configuration.Todd Fiala2015-10-251-1/+1
| | | | llvm-svn: 251264
* Xcode: added lldb-gtest target to build and run the gtests in the unittests ↵Todd Fiala2015-10-253-0/+19
| | | | | | | | | | | | | | | | | | | | directory. Also added a placeholder Editline gtest for some code that I'll add as soon as I make sure this addition doesn't break any of the build bots. This change also introduces some Xcode user-defined variables that I've used to attempt to isolate the way Python is integrated into the build. I don't have the rest of LLDB using it yet, I'm using the gtests as my guinea pig on that. Currently these are: PYTHON_FRAMEWORK_PATH PYTHON_VERSION_MAJOR PYTHON_VERSION_MINOR I will convert the rest over to it after this gets a little time to bake and any kinks are worked out of it. llvm-svn: 251261
* Add a new task pool class to LLDBTamas Berghammer2015-10-202-0/+63
| | | | | | | | | | | | | | | | | | | | | | The purpose of the class is to make it easy to execute tasks in parallel Basic design goals: * Have a very lightweight and easy to use interface where a list of lambdas can be executed in parallel * Use a global thread pool to limit the number of threads used (std::async don't do it on Linux) and to eliminate the thread creation overhead * Destroy the thread currently not in use to avoid the confusion caused by them during debugging LLDB Possible future improvements: * Possibility to cancel already added, but not yet started tasks * Parallel for_each implementation * Optimizations in the thread creation destroyation code Differential revision: http://reviews.llvm.org/D13727 llvm-svn: 250820
* Convert SWIG typemap string operations to PythonObjects.Zachary Turner2015-10-161-0/+11
| | | | llvm-svn: 250530
* Split Socket class into Tcp/Udp/DomainSocket subclasses.Oleksiy Vyalov2015-10-151-31/+84
| | | | | | http://reviews.llvm.org/D13754 llvm-svn: 250474
* Introduce a `PythonFile` object, and use it everywhere.Zachary Turner2015-10-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Python file handling got an overhaul in Python 3, and it affects the way we have to interact with files. Notably: 1) `PyFile_FromFile` no longer exists, and instead we have to use `PyFile_FromFd`. This means having a way to get an fd from a FILE*. For this we reuse the lldb_private::File class to convert between FILE*s and fds, since there are some subtleties regarding ownership rules when FILE*s and fds refer to the same file. 2) PyFile is no longer a builtin type, so there is no such thing as `PyFile_Check`. Instead, files in Python 3 are just instances of `io.IOBase`. So the logic for checking if something is a file in Python 3 is to check if it is a subclass of that module. Additionally, some unit tests are added to verify that `PythonFile` works as expected on Python 2 and Python 3, and `ScriptInterpreterPython` is updated to use `PythonFile` instead of manual calls to the various `PyFile_XXX` methods. llvm-svn: 250444
* Get Python unit tests working with Python 3.Zachary Turner2015-10-141-260/+173
| | | | | | | | | | | | | | | | | | | | | There were a couple of issues related to string handling that needed to be fixed. In particular, we cannot get away with converting `PyUnicode` objects to `PyBytes` objects and storing the `PyBytes` regardless of Python version. Instead we have to store a `PyUnicode` on Python 3 and a `PyString` on Python 2. The reason for this is that if you call `PyObject_Str` on a `PyBytes` in Python 3, it will return you a string that actually contains the string value wrappedin the characters b''. So if we create a `PythonString` with the value "test", and we call Str() on it, we will get back the string "b'test'", which breaks string equality. The only way to fix this is to store a native `PyUnicode` object under Python 3. With this CL, ScriptInterpreterPythonTests unit tests pass 100% under Python 2 and Python 3. llvm-svn: 250327
* Fix ref counting of Python objects.Zachary Turner2015-10-131-43/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PythonObjects were being incorrectly ref-counted. This problem was pervasive throughout the codebase, leading to an unknown number of memory leaks and potentially use-after-free. The issue stems from the fact that Python native methods can either return "borrowed" references or "owned" references. For the former category, you *must* incref it prior to decrefing it. And for the latter category, you should not incref it before decrefing it. This is mostly an issue when a Python C API method returns a `PyObject` to you, but it can also happen with a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`, which is documented to "steal" the reference that you give it. So if you pass something to `PyList_SetItem`, you cannot hold onto it unless you incref it first. But since this is one of only two exceptions in the entire API, it's confusing and difficult to remember. Our `PythonObject` class was indiscriminantely increfing every object it received, which means that if you passed it an owned reference, you now have a dangling reference since owned references should not be increfed. We were doing this in quite a few places. There was also a fair amount of manual increfing and decrefing prevalent throughout the codebase, which is easy to get wrong. This patch solves the problem by making any construction of a `PythonObject` from a `PyObject` take a flag which indicates whether it is an owned reference or a borrowed reference. There is no way to construct a `PythonObject` without this flag, and it does not offer a default value, forcing the user to make an explicit decision every time. All manual uses of `PyObject` have been cleaned up throughout the codebase and replaced with `PythonObject` in order to make RAII the predominant pattern when dealing with native Python objects. Differential Revision: http://reviews.llvm.org/D13617 Reviewed By: Greg Clayton llvm-svn: 250195
* Port native Python-API to 3.xZachary Turner2015-10-094-0/+421
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, liblldb is 95% of the way towards being able to work under both Python 2.x and Python 3.x. This should introduce no functional change for Python 2.x, but for Python 3.x there are some important changes. Primarily, these are: 1) PyString doesn't exist in Python 3. Everything is a PyUnicode. To account for this, PythonString now stores a PyBytes instead of a PyString. In Python 2, this is equivalent to a PyUnicode, and in Python 3, we do a conversion from PyUnicode to PyBytes and store the PyBytes. 2) PyInt doesn't exist in Python 3. Everything is a PyLong. To account for this, PythonInteger stores a PyLong instead of a PyInt. In Python 2.x, this requires doing a conversion to PyLong when creating a PythonInteger from a PyInt. In 3.x, there is no PyInt anyway, so we can assume everything is a PyLong. 3) PyFile_FromFile doesn't exist in Python 3. Instead there is a PyFile_FromFd. This is not addressed in this patch because it will require quite a large change to plumb fd's all the way through the system into the ScriptInterpreter. This is the only remaining piece of the puzzle to get LLDB supporting Python 3.x. Being able to run the test suite is not addressed in this patch. After the extension module can compile and you can enter an embedded 3.x interpreter, the test suite will be addressed in a followup. llvm-svn: 249886
* Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()Bruce Mitchener2015-10-062-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `module_spec.GetFileSpec().GetDirectory().AsCString()` returned a `nullptr` this line caused a segmentation fault: `std::string module_directory = module_spec.GetFileSpec().GetDirectory().AsCString()` Some context: I was remote debugging an executable built with Clang in an Ubuntu VM on my Windows machine using lldb-mi. I copied the executable and nothing else from the Ubuntu VM to the Windows machine. Then started lldb-server in the Ubuntu VM: ``` ./bin/lldb-server gdbserver *:8888 -- /home/enlight/Projects/dbgmits/build/Debug/data_tests_target ``` And ran `lldb-mi --interpreter` on Windows with the following commands: ``` -file-exec-and-symbols C:\Projects\data_tests_target -target-select remote 192.168.56.101:8888 -exec-continue ``` After which the segmentation fault occurred at the aforementioned line. Inside this method `module_spec.GetFileSpec()` returns an empty `FileSpec` (no dir, no filename), while `module_spec.GetSymbolFileSpec().GetFilename()` returns `"libc-2.19.so"`. Patch thanks to Vadim Macagon. Reviewers: brucem, zturner, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13201 llvm-svn: 249387
* Make UriParser to support [$HOSTNAME] notation.Oleksiy Vyalov2015-08-201-0/+24
| | | | | | http://reviews.llvm.org/D12025 llvm-svn: 245639
OpenPOWER on IntegriCloud