Commit Graph

64 Commits

Author SHA1 Message Date
Pavel Labath df2ad4c531 Add unit tests for ModuleCache
Reviewers: ovyalov, zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D20570

llvm-svn: 270684
2016-05-25 10:48:16 +00:00
Bryan Chan 01319e93ab Avoid an assertion failure when a bit field is extracted from a value of the 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
2016-05-19 13:51:20 +00:00
Pavel Labath d86bc2af27 Fix SymbolFilePDBTests.cpp
llvm-svn: 269057
2016-05-10 13:46:22 +00:00
Pavel Labath ef984e7dc0 Revert "Add a read_full_buffer argument to ConnectionFileDescriptor::Read"
This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to
ConnectionGenericFileWindows).

llvm-svn: 268384
2016-05-03 14:07:41 +00:00
Pavel Labath 240760207e Add a read_full_buffer argument to ConnectionFileDescriptor::Read
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
2016-05-03 13:55:53 +00:00
Pavel Labath 2f13da3ea4 Fix compiler warnings in SymbolFilePDBTests
llvm-svn: 267688
2016-04-27 10:40:52 +00:00
Zachary Turner b987df4b17 Add missing file needed for PDB unittests.
llvm-svn: 266886
2016-04-20 16:41:02 +00:00
Ulrich Weigand 9521ad2a49 Fix usage of APInt.getRawData for big-endian systems
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
2016-04-15 09:55:52 +00:00
Zachary Turner 42dff79068 Initial support for reading type information from PDBs.
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
2016-04-15 00:21:26 +00:00
Ulrich Weigand da70c17bfc Revert r266311 - Fix usage of APInt.getRawData for big-endian systems
Try to get 32-bit build bots running again.

llvm-svn: 266341
2016-04-14 17:22:18 +00:00
Ulrich Weigand 461bd680c3 Handle bit fields on big-endian systems correctly
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
2016-04-14 14:32:57 +00:00
Ulrich Weigand ca07434234 Fix usage of APInt.getRawData for big-endian systems
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
2016-04-14 14:32:01 +00:00
Pavel Labath a212c58db0 FileSpec: make matching separator-agnostic again
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
2016-04-14 09:38:06 +00:00
Pavel Labath b0743fb2e9 Remove obsolete comments
llvm-svn: 266196
2016-04-13 13:26:45 +00:00
Enrico Granata 15d1b4e2aa Initialize the Python script interpreter lazily (i.e. not at debugger startup)
This time it should also pass the gtests

llvm-svn: 266103
2016-04-12 18:23:18 +00:00
Pavel Labath 144119b86d Make FileSpec handling platform-independent
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
2016-04-04 14:39:12 +00:00
Zachary Turner 9d8a97ebd1 Add some unit tests for ClangASTContext.
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
2016-04-01 23:20:35 +00:00
Pavel Labath 021ccdb7cd Fix SocketAddressTest (again)
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
2016-03-30 09:43:04 +00:00
Pavel Labath d81b2ccb4f Fix a bunch of signedness warnings in unittests
llvm-svn: 263209
2016-03-11 09:00:23 +00:00
Pavel Labath cc0e87cdae Fix a couple of cornercases in FileSpec + tests
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
2016-03-11 08:44:44 +00:00
Zachary Turner 74e08ca05c Add support for reading line tables from PDB files.
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
2016-03-02 22:05:52 +00:00
Pavel Labath 5a8453d576 Fix PythonDataObjectsTests for python 2
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
2016-02-25 17:41:59 +00:00
Zachary Turner 8d39b2a213 Fix SocketTest on Windows.
Differential Revision: http://reviews.llvm.org/D17106

llvm-svn: 261240
2016-02-18 18:49:56 +00:00
Zachary Turner 657f930824 Change `CoreTests` to LLDBCoreTests to avoid name clash.
lld was already using a target named CoreTests so CMake
was erroring due to this conflict.

llvm-svn: 260326
2016-02-09 23:45:21 +00:00
Pavel Labath b625a0e1bc Fix invalid shift operator overload in Scalar
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
2016-02-09 17:28:01 +00:00
Reid Kleckner de9dfe7888 Fix sign conversion warnings in LLDB Python unittests
llvm-svn: 259689
2016-02-03 20:48:09 +00:00
Pavel Labath 1b58f5cbbb Fix an off-by-one in SocketTest::DecodeHostAndPort
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
2016-02-03 11:12:23 +00:00
Zachary Turner f9d6d204e8 Fix swig typemap for SBEvent.
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
2016-01-25 23:21:09 +00:00
Todd Fiala 16c4e16c35 added test fixture to EditlineTest gtest
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
2016-01-22 21:58:55 +00:00
Zachary Turner 5a72c02be9 Introduce a PythonBytes class into PythonDataObjects.
This class behaves the same as PythonString on Python2, but differently
on Python3.  Unittests are added as well.

llvm-svn: 257397
2016-01-11 22:16:12 +00:00
Zachary Turner a87d0ae61b Fix a bug in PythonExceptionState and add unittest coverage.
I forgot to reset the restore flag when calling member function
`Acquire`.  The newly added unittest should cover this case.

llvm-svn: 253002
2015-11-13 01:50:19 +00:00
Zachary Turner 3946247caf Introduce a `PythonExceptionState` class.
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
2015-11-13 01:24:52 +00:00
Zachary Turner c946d46283 gtest - Make a `PythonTestSuite` base class for setup / teardown.
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
2015-11-13 01:24:35 +00:00
Zachary Turner a140514733 Create `PythonTuple` and `PythonCallable` wrapper classes.
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
2015-11-11 19:42:27 +00:00
Zachary Turner 7841efbb92 Add a `PythonModule` class, and a root-level method for resolving names.
llvm-svn: 252765
2015-11-11 17:59:49 +00:00
Ryan Brown 0fbd187d79 Fix build for go parser unittest.
llvm-svn: 252007
2015-11-03 22:46:37 +00:00
Ryan Brown 998c8a1c1c Create an expression parser for Go.
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
2015-11-02 19:30:40 +00:00
Todd Fiala 45557e34d9 Added real editline tests.
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
2015-10-30 02:54:52 +00:00
Todd Fiala 7b6f77e85b Fix a copy-and-paste error on new Editline test cmake configuration.
llvm-svn: 251264
2015-10-25 21:54:56 +00:00
Todd Fiala 528a30d62c Xcode: added lldb-gtest target to build and run the gtests in the unittests 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
2015-10-25 21:42:35 +00:00
Tamas Berghammer ccb367609b Add a new task pool class to LLDB
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
2015-10-20 12:42:05 +00:00
Zachary Turner 7d6d218e12 Convert SWIG typemap string operations to PythonObjects.
llvm-svn: 250530
2015-10-16 17:51:49 +00:00
Oleksiy Vyalov e98628cecb Split Socket class into Tcp/Udp/DomainSocket subclasses.
http://reviews.llvm.org/D13754

llvm-svn: 250474
2015-10-15 23:54:09 +00:00
Zachary Turner 9c40264fda Introduce a `PythonFile` object, and use it everywhere.
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
2015-10-15 19:35:48 +00:00
Zachary Turner 18426935ac Get Python unit tests working with Python 3.
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
2015-10-14 21:06:13 +00:00
Zachary Turner f8b22f8fea Fix ref counting of Python objects.
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
2015-10-13 18:16:15 +00:00
Zachary Turner 22c8efcd34 Port native Python-API to 3.x
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
2015-10-09 19:45:41 +00:00
Bruce Mitchener eb284e4667 Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()
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
2015-10-06 10:17:34 +00:00
Oleksiy Vyalov 549718563d Make UriParser to support [$HOSTNAME] notation.
http://reviews.llvm.org/D12025

llvm-svn: 245639
2015-08-20 23:09:34 +00:00
Zachary Turner 2c1f46dcc6 Convert the ScriptInterpreter system to a plugin-based one.
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter.  This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.

This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.

Any new code interfacing with the Python C API must live in this location
from here on out.  Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.

Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton

llvm-svn: 243681
2015-07-30 20:28:07 +00:00