Commit Graph

25 Commits

Author SHA1 Message Date
Chris Bieneman 07522bb187 [CMake] Don't add gtest if it is already there
LLVM build trees export the gtest library through a special export set. If you're building against a build tree you shouldn't need to re-add gtest, but if you're building against an installed LLVM you do.

llvm-svn: 288691
2016-12-05 19:40:34 +00:00
Michal Gorny 1f368434f0 [cmake] Build gtest from LLVM when building standalone
Include the gtest utility directory from LLVM sources when performing
a stand-alone build of LLDB. This is necessary to have a correct gtest
library to link tests against, as the one used by LLVM is not installed
(and not supposed to be). This is the same approach as used in clang.

Differential Revision: https://reviews.llvm.org/D26245

llvm-svn: 285865
2016-11-02 22:57:23 +00:00
Jason Molenda 74b8fbcba7 Re-commit the changes from r282565 that I had to back out because of
a linux bot test failure.  That one is fixed; hopefully there won't
be any others turned up this time.

The eh_frame augmentation code wasn't working right after the 
reorg/rewrite of the classes.  It works correctly now for the one
test that was failing - but we'll see what the test bots come up
with. 

<rdar://problem/28509178> 

llvm-svn: 282659
2016-09-29 01:00:16 +00:00
Jason Molenda 536ff0dd2f Reverting r282565.
A testbot found a regression introduced in the testsuite with
the changes in r282565 on Ubuntu (TestStepNoDebug.ReturnValueTestCase).
I'll get this set up on an ubuntu box and figure out what is happening
there -- likely a problem with the eh_frame augmentation, which isn't
used on macosx.

llvm-svn: 282566
2016-09-28 03:16:14 +00:00
Jason Molenda 1c9858b298 Refactor the x86 UnwindAssembly class into a separate class called
x86AssemblyInspectionEngine and the current UnwindAssembly_x86 to
allow for the core engine to be exercised by unit tests.

The UnwindAssembly_x86 class will have access to Targets, Processes,
Threads, RegisterContexts -- it will be working in the full lldb
environment.

x86AssemblyInspectionEngine is layered away from all of that, it is
given some register definitions and a bag of bytes to profile.

I wrote an initial unittest for a do-nothing simple x86_64/i386
function to start with.  I'll be adding more.

The x86 assembly unwinder was added to lldb early in its bringup;
I made some modernization changes as I was refactoring the code
to make it more consistent with how we write lldb today.

I also added RegisterContextMinidump_x86_64.cpp to the xcode project
file so I can run the unittests from that.

The testsuite passes with this change, but there was quite a bit of
code change by the refactoring and it's possible there are some 
issues.  I'll be testing this more in the coming days, but it looks
like it is behaving correctly as far as I can tell with automated
testing.

<rdar://problem/28509178> 

llvm-svn: 282565
2016-09-28 02:52:19 +00:00
Zachary Turner 6fa7681bb6 Convert many functions to use StringRefs.
Where possible, remove the const char* version.  To keep the
risk and impact here minimal, I've only done the simplest
functions.

In the process, I found a few opportunities for adding some
unit tests, so I added those as well.

Tested on Windows, Linux, and OSX.

llvm-svn: 281799
2016-09-17 02:00:02 +00:00
Pavel Labath 9361c439e8 Fix parsing of complicated C++ names
Summary:
CPlusPlusLanguage::MethodName was not correctly parsing templated functions whose demangled name
included the return type -- the space before the function name was included in the "context" and
the context itself was not terminated correctly due to a misuse of the substr function (second
argument is length, not the end position). Fix that and add a regression test.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D23608

llvm-svn: 279038
2016-08-18 08:21:38 +00:00
Pavel Labath 8c1b6bd7d2 Reapply "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
  stopped due to a different reason - the interrupt request would remain queued and would
  interfere with the following "continue". I also added a unit test for this case.

This reapplies r277156 and r277139.

llvm-svn: 278118
2016-08-09 12:04:46 +00:00
Pavel Labath 4cb699260c Revert "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)

llvm-svn: 277154
2016-07-29 15:41:52 +00:00
Pavel Labath e768c4b858 Rewrite gdb-remote's SendContinuePacketAndWaitForResponse
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with
several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any
changes to how packet sending functions and threads interact was very difficult and error-prone.

This change does not add any functionality yet, it merely paves the way for future changes. In a
follow-up, I plan to add the ability to have multiple query packets in flight (i.e.,
request,request,response,response instead of the usual request,response sequences) and use that
to speed up qModuleInfo packet processing.

Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread,
and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and
blocks any other async threads from accessing the connection. Other threads create an instance of
the Lock object when they want to access the connection. This object, while in scope prevents the
continue from being send. Optionally, it can also interrupt the process to gain access to the
connection for async processing.

Most of the syncrhonization logic is encapsulated within these two classes. Some of it still
had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much
more manageable than before -- partly because of most of the work is done in the ContinueLock
class, and partly because I have factored out a lot of the packet processing code separate
functions (this also makes the functionality more easily testable). Most importantly, there is
none of syncrhonization code in the async thread users -- as far as they are concerned, they just
need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a
very thin wrapper around the NoLock version of the function, whereas previously it had over 100
lines of synchronization code).  This will make my follow up changes there easy.

I have written a number of unit tests for the new code and I have ran the test suite on linux and
osx with no regressions.

Subscribers: tberghammer

Differential Revision: https://reviews.llvm.org/D22629

llvm-svn: 277139
2016-07-29 13:10:02 +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
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 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
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 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
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
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
Pavel Labath c076559a5b [NativeProcessLinux] fold ThreadStateCoordinator into NPL
Summary:
Since all TSC operations are now executed synchronously, TSC has become a little more than a
messenger between different parts of NativeProcessLinux. Therefore, the reason for its existance
has disappeared.

This commit moves the contents of the TSC into the NPL class. This will enable us to remove all
the boilerplate code in NPL (as it stands now, this is most of the class), which I plan to do in
subsequent commits.

Unfortunately, this also means we will lose the unit tests for the TSC. However, since the size
of the TSC has diminished, the unit tests were not testing much at this point anyway, so it's not
a big loss.

No functional change.

Test Plan: All tests continue to pass.

Reviewers: vharron, chaoren

Subscribers: lldb-commits

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

llvm-svn: 236587
2015-05-06 10:46:34 +00:00
Pavel Labath 980b92a8e6 Add missing libraries to unittest link
Summary:
Currently, linking of the unittests fails on linux because it is missing a bunch of symbols from
libedit, curses, etc. This fixes the build by adding the correct dependencies.

Test Plan: Linking works, unit tests run.

Reviewers: zturner

Subscribers: lldb-commits

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

llvm-svn: 235853
2015-04-27 09:26:03 +00:00
Zachary Turner 799770c03a Fix linking of unit tests via CMake on Windows.
A previous attempt to make the unit tests link properly on
Linux broke it for Windows.  This patch fixes it for both platforms.

llvm-svn: 232648
2015-03-18 16:56:24 +00:00
Zachary Turner 85bc48ca74 Convert CRLF to LF.
I accidentally let some Windows line endings slip in.  This is a
good reminder for me to use core.eol=lf.

llvm-svn: 232560
2015-03-17 22:51:21 +00:00
David Blaikie 3dfb86b641 Fix the clang -Werror build & make the unit tests link under Linux
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.

llvm-svn: 232461
2015-03-17 03:32:21 +00:00
Zachary Turner 073951f28b Fix a bug related to arg escaping, and add unit tests.
A recent refactor had introduced a bug where if you escaped a
character, the rest of the string would get processed incorrectly.

This patch fixes that bug and adds some unit tests for Args.

llvm-svn: 232288
2015-03-14 23:39:42 +00:00
Zachary Turner eeba1a896a [CMake] Make the unittests link against everything...
Sigh.  There's really not a good alternative until we decouple
python from lldb better.  The only way the build works right now
is by having every executable link against every LLDB library.
This causes implicit transitive link dependencies on the union
of everything that LLDB brings in.  Which means that if all we
want is one header file from interpreter, we have to bring in
everything, including everything that everything depends on,
which means python.

There's outstanding efforts to address this, but it's not yet
complete.  So until then, this is all we can do.

llvm-svn: 232287
2015-03-14 23:39:28 +00:00
Zachary Turner 719ec93a74 Rework the gtest directory structure.
This makes the directory structure mirror the canonical LLVM
directory structure for a gtest suite.

Additionally, this patch deletes the xcode project.  Nobody
is currently depending on this, and it would be better to have
gtest unit tests be hand-maintained in the Xcode workspace
rather than using this python test runner.  Patches to that
effect will be submitted as followups.

llvm-svn: 232211
2015-03-13 20:54:57 +00:00