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
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
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
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
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
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
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)
llvm-svn: 277154
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Jason Molenda