And update the comment describing the reason this test is skipped.
Unlike the issue described llvm.org/pr22784 this test sometimes causes
a hang on my local machine and is not just a problem on the retired
buildbot.
This reverts commit r247013.
llvm-svn: 247024
This test passes locally but was disabled due to pexpect issues on the
FreeBSD buildbot. That buildbot has been retired as it was overloaded,
and we will investigate again if this fails once a new buildbot is in
place. Noted by John Wolfe.
llvm.org/pr22784
llvm-svn: 247013
Summary:
- Bug 24457 can now be tested for inferiors compiled
by clang compiler also.
- A generic test case for GCC and Clang inferiors:
-- Works even when Clang and GCC produce different
assembly for the same inferior.
- Refer Differential Revision: http://reviews.llvm.org/D12677
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
llvm-svn: 247000
Summary:
For an array declared like "blk[2][3]", this command was showing:
-data-evaluate-expression blk
^done,value="{[0] = [3], [1] = [3]}"
After this fix, it shows:
-data-evaluate-expression blk
^done,value="{[0] = {[0] = 1, [1] = 2, [2] = 3}, [1] = {[0] = 4, [1] = 5, [2] = 6}}"
The code to do the right thing was already available and used by other commands.
So I have just used that and removed the half-baked previous implementation.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12634
llvm-svn: 246965
- clang is picky about inline assembly: add the correct instruction size suffix
- mark the new test as expectedFailureClang: the test fails as the breakpoint is set in the wrong
place
llvm-svn: 246957
Summary:
- For 'register read --all' command on x86_64-Linux Platform:
-- Provide correct values of X87 FPU Special Purpose Registers
-- Both 32-bit & 64-bit inferiors give correct values on this
Platform
- Added a Test Vector:
-- To verify the expected behaviour of the command
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ashok.thirumurthi, granata.enrico, tfiala, clayborg
Differential Revision: http://reviews.llvm.org/D12592
llvm-svn: 246955
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
There was a race condition in the AsyncThread, where we would end up sending a vAttach
notification to the thread before it got a chance set up its listener (this can be reproduced by
adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then
get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the
ProcessGDBRemote constructor.
This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from
TestAttachResume, and will watch the buildbots for signs of trouble.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12552
llvm-svn: 246756
Instead of fixing these tests by finding a pexpect replacement,
this set of tests can be fixed by re-writing the test to not use
pexpect.
llvm.org/pr24679
llvm-svn: 246671
If a command argument contains a space then it have to be escaped with
backslash signs so the argument parsing logic can parse it properly.
This CL fixes the tab completion code for the arguments to create
complitions with correctly escaped strings.
Differential revision: http://reviews.llvm.org/D12531
llvm-svn: 246639
Summary:
The test (among other things) attempts to verify that detaching works while the inferior is
running. However, this was racy since the inferior could end up stopping again before we got a
chance to detach from it (the test could be made to fail reliably by inserting a sleep just after
the last "continue" command). The reason for the stop was that we had a breakpoint set in a place
that can be hit by multiple threads, and we stop because another thread hit a breakpoint.
I fix this by moving the breakpoint to a place that is reachable from only one thread. I also
make sure that the same thread cannot hit the breakpoint if we are exceptionaly slow by flipping
a flag which makes the breakpoint unreachable (I cannot just disable or delete the breakpoint as
the test makes it a point to try detaching while breakpoints are still set).
Another source or racyness was that the test verified that the process resumes and
stops after a "continue". However, if these two events happened too fast, the initial start event
would be lost, and the test would end up confused. I have implemented this in a safer manner and
made a utility function out of it, as I know of a couple of other tests which need the same
functionality.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12527
llvm-svn: 246623
These tests work when run locally. They had been occasionally failing
on the FreeBSD buildbot due to pexpect issues. That buildbot is
currently down, and I expect the replacement will not have this issue.
llvm.org/pr22784
llvm-svn: 246490
This test runs fine on its own, but leaves python in a bad state to
where all tests that run after it error out. See llvm.org/pr24575.
This resolves the concerns raised in http://reviews.llvm.org/rL237053.
Reviewed by: clayborg, ted
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12329
llvm-svn: 246043
Ed Maste