Currently most of the test files have a separate dwarf and a separate
dsym test with almost identical content (only the build step is
different). With adding dwo symbol file handling to the test suit it
would increase this to a 3-way duplication. The purpose of this change
is to eliminate this redundancy with generating 2 test case (one dwarf
and one dsym) for each test function specified (dwo handling will be
added at a later commit).
Main design goals:
* There should be no boilerplate code in each test file to support the
multiple debug info in most of the tests (custom scenarios are
acceptable in special cases) so adding a new test case is easier and
we can't miss one of the debug info type.
* In case of a test failure, the debug symbols used during the test run
have to be cleanly visible from the output of dotest.py to make
debugging easier both from build bot logs and from local test runs
* Each test case should have a unique, fully qualified name so we can
run exactly 1 test with "-f <test-case>.<test-function>" syntax
* Test output should be grouped based on test files the same way as it
happens now (displaying dwarf/dsym results separately isn't
preferable)
Proposed solution (main logic in lldbtest.py, rest of them are test
cases fixed up for the new style):
* Have only 1 test fuction in the test files what will run for all
debug info separately and this test function should call just
"self.build(...)" to build an inferior with the right debug info
* When a class is created by python (the class object, not the class
instance), we will generate a new test method for each debug info
format in the test class with the name "<test-function>_<debug-info>"
and remove the original test method. This way unittest2 see multiple
test methods (1 for each debug info, pretty much as of now) and will
handle the test selection and the failure reporting correctly (the
debug info will be visible from the end of the test name)
* Add new annotation @no_debug_info_test to disable the generation of
multiple tests for each debug info format when the test don't have an
inferior
Differential revision: http://reviews.llvm.org/D13028
llvm-svn: 248883
The timeout mechanism has been implemented in python,
so there is no more dependence on external utilities
for timing out an inferior dotest.py process.
Platform-specific bits are implemented for POSIX-like
and Windows platforms. There is a small class named
ProcessHelper in process_control.py that needs to be
overridden for platforms that fall outside of the
POSIX-like and Windows platforms.
See http://reviews.llvm.org/D13124 for more details.
llvm-svn: 248834
See the script comments for how to modify your
pylintrc file (e.g. $HOME/.pylintrc) to support
always finding the lldb-specific Python library
directories.
With the pylintrc modification using this script,
the lldb python tests and test inferstructure can
be linted on any of potentially multiple lldb source
trees on the system without further work from
the developer.
llvm-svn: 248676
These tests used to hang on the old FreeBSD buildbot, which has been
retired. They do not hang when run locally, but do fail.
llvm.org/pr24939
llvm-svn: 248577
These tests were skipped because they hung the old FreeBSD buildbot.
They pass (and do not hang) when run locally so enable them again. We
will investigate further if they hang again once the new FreeBSD
buildbot is installed.
llvm.org/pr16684
llvm.org/pr18200
llvm.org/pr18230
llvm-svn: 248574
This test used fail intermittently, but now passes consistently on
FreeBSD in local runs. We'll investigate further if it's intermittent
on the FreeBSD buildbot, once it's restored.
llvm.org/pr15039
llvm-svn: 248410
Summary:
With this change DWARFASTParserClang::CompleteTypeFromDWARF returns false if
DWARFASTParserClang::ParseChildMembers returns false. Similarly, it returns
false if any base class is of an incomplete type. This helps in cases like
these:
class Foo
{
public:
std::string str;
};
...
Foo f;
If a file with the above code is compiled with a modern clang but without
the -fno-limit-debug-info (or similar) option, then the DWARF has only
a forward declration for std::string. In which case, the type for
"class Foo" cannot be completed. If LLDB does not detect that a child
member has incomplete type, then it wrongly conveys to clang (the LLDB
compiler) that "class Foo" is complete, and consequently crashes due to
an assertion failure in clang when running commands like "p f" or
"frame var f".
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13066
llvm-svn: 248401
* --results-formatter-options renamed to --results-formatter-option,
with short version of -O
* Multiple --results-formatter-option=OPTION can be specified. The
comma-separating mechanism has been removed.
* XunitFormatter options modified: -n and -r are now short forms of
--ignore-skip-name and --ignore-skip-reason. Those long option
names were tweaked lightly. They also can be specified multiple
times on the command line. The comma-separating, multiple-pattern-
per-option mechanism has been removed.
One can now specify:
dotest.py --results-file stdout -O-ndsym -O-nlldb-mi
for example, to ignore reporting skips for dsym-related or lldb-mi-related
tests in the xUnit report.
llvm-svn: 248384
Summary:
The following situation occured in TestAttachResume:
The inferior was stoped at a breakpoint and we did a continue, immediately followed by a detach.
Since there was a trap instruction under the IP, the continue did a step-over-breakpoint before
resuming the inferior for real. In some cases, the detach command was executed between these two
events (after the step-over stop, but before continue). Here, public state was running, but
private state was stopped. This caused a problem because HaltForDestroyOrDetach was checking the
public state to see whether it needs to stop the process (call Halt()), but Halt() was checking
the private state and concluded that there is nothing for it to do.
Solution: Instead of Halt() call SendAsyncInterrupt(), which will then cause Halt() to be
executed in the context of the private state thread. I also rename HaltForDestroyOrDetach to
reflect it does not call halt directly.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13056
llvm-svn: 248371
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
Reviewers: jingham, ovyalov, spyffe, richard.mitton, clayborg
Differential Revision: http://reviews.llvm.org/D12404
llvm-svn: 248366
When doing test event collation from dotest inferiors to the parallel test
runner, I had a hard-coded small value for the socket backlog. Fix it to
be 2*num workers so we don't fail socket connections from inferiors.
llvm-svn: 248337
I'm seeing timed out tests not properly timing out on the Linux
build bot after this change. Not sure if it is related but
seems suspect.
llvm-svn: 248284
These two tests are skipped on Linux with a comment that the behaviour
is as expected, but they are consistently passing on FreeBSD now.
llvm.org/pr15989
llvm-svn: 248271
Skipped tests can be dropped from xUnit reports if either
the name or the skip reason matches one of a given set of
regular expression patterns (via re.search(), not re.match()).
New formatter option for the xunit formatter:
--ignore-skip-matching-reason and
--ignore-skip-matching-name
Both are results-formatter options.
llvm-svn: 248247
Added key press handling and a first responder system and the ability for windows that can be first responders to be selected and have key presses routed to the first resonder, delegates and also travel up the parent chain.
Remove the temp file that was being created.
llvm-svn: 248232
The parallel test runner now sends the terminate event to the formatter
(if there is one) after the parallel test runs but before dumping anything
to stdout/stderr at the end of the run. This allows the existing
stdout/stderr summary reporting to co-exist nicely with a formatter like
the test_results.Curses that otherwise clobbers the screen.
llvm-svn: 248228
- rename "Failures" window to "Completed Tests"
- Remove the extra lock that I incorrectly added to the ResultsFormatter as it already had one
- Init the curses GUI with the right number of jobs when handling the "intialize" event
- tear down the curses GUI when tests complete
llvm-svn: 248179
Test fails with:
error: Process 1 was reported after connecting to
'connect://localhost:42922', but no stop reply packet was received
llvm.org/pr24896
llvm-svn: 248157
On OS X, we're occasionally seeing sighups come in to what
looks like the whole test runner process group (all the
multiprocessing workers and the main process). It's not due
to a lost console. This change has the main parallel test runner
process and the child worker processes ignore sighup.
Covers:
https://llvm.org/bugs/show_bug.cgi?id=24846
llvm-svn: 248141
The test events had worker indexes coming across as strings. I
want them to be ints. worker_index now comes across as an int in
the dicationary.
The optional type can be specified with:
--event-add-entries key=val[:type][,key2=val2[:type2]...]
The type piece may be 'int' at this time. That is all. Otherwise
it will be a string.
llvm-svn: 248066
The failure mode when one gets this wrong is quite gnarly to then walk oneself out of, and if you can't actually find the library, trying to build against it is fairly pointless anyway
This + my previous skip_if_library_missing change should make running the libc++ tests on a Linux machine without it much more seamless
llvm-svn: 248057
Now does proper Unicode code region scanning for invalid XML
characters. Strips out XML-invalid characters.
Does this for:
failure result: message, backtrace
error result: message, backtrace
skipped test: skip reason
pexpect timeouts were still generating characters that would break
XML readers (correctly so).
llvm-svn: 247998
When pexpect errors occurred, the <error>/<failure> element's
message attribute could get too long and contain
invalid characters for xml attributes, even when quoted.
Particularly for pexpect failures.
Now <error> and <failure> entries truncate the message
attribute to contain the first line of the message.
<error> and <failure> blocks now contain both the
complete message and the backtrace (finally!) in the
text body of the error/failure element.
llvm-svn: 247973
The Jenkins JUnit publisher handled our output, but
the Jenkins xUnit plugin's JUnit support did not like
that we didn't have a <testsuites> element wrapping
everything. They both work with this fix.
llvm-svn: 247962
This fixes -data-info-line and -symbol-list-lines to parse the filename
and line correctly when line entries don't have the optional column
number and the filename contains a Windows drive letter. It also fixes
-symbol-list-lines when code from header files is generated.
Reviewed by: abidh, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12115
llvm-svn: 247899
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
Summary: Supports the parsing of the "using namespace XXX" and "using XXX::XXX" directives. Added ambiguity errors when it two decls with the same name are encountered (see comments in TestCppNsImport). Fixes using directives being duplicated for anonymous namespaces. Fixes GetDeclForUID for specification DIEs.
Reviewers: sivachandra, chaoren, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12897
llvm-svn: 247836
ExprCommandWithTimeoutsTestCase::expectedFailureFreeBSD had an
expectedFailureFreeBSD decorator, removed in r247799. It had been flakey
on the FreeBSD buildbot but passed locally. John Wolfe has since
observed a local failure, so add expectedFlakeyFreeBSD until we can
investigate and likely increase the timeout in the test.
llvm.org/pr19605 (FreeBSD)
llvm.org/pr20275 (equivalent Linux issue)
llvm-svn: 247822
ExprCommandWithTimeoutsTestCase::expectedFailureFreeBSD
This test passes locally but was marked XFAIL due to failures 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.
llvm.org/pr19605
llvm-svn: 247799
Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
Marked XFAIL for:
clang - all versions < 3.5. I verified the first version it passes on Linux is 3.5.
clang - version 3.7 (verified this fails)
clang - TOT/3.8 (verified this currently fails)
Ideally we dig into why this started failing and (hopefully) get this passing again.
llvm-svn: 247664
Summary:
Linux with ToT clang (3.8) fails.
This reverts commit r247633.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12868
llvm-svn: 247648
Linux/clang on clang 3.6+ is passing this test. As OS X was
in a similar position, I'm guessing this was fixed by a recent
compiler. Might work on 3.5/3.4, but it is definitely working
on clang 3.6. I didn't break out FreeBSD since this appears to
be related to a compiler fix.
llvm-svn: 247633
TestPersistObjCPointeeType and TestObjCNewSyntax marked up to expect
success on clang >= 7.0.0.
TestMultipleDebuggers passed 25/25 times, taking off intermittent.
If this changes, I'll make sure it goes into a flaky/flakey category.
llvm-svn: 247601
Related to these two test case classes:
test/driver/batch_mode/TestBatchMode.py
test/functionalities/inferior-assert/TestInferiorAssert.py
llvm-svn: 247567
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
This re-applies r247013.
llvm-svn: 247565
This test passes locally but was marked XFAIL due to failures 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.
llvm.org/pr23747
llvm-svn: 247562
This is a trivial issue to fix, just marking it for later.
Windows prints function signatures a bit differently, and the
test expects a specific format.
llvm-svn: 247457
This patch fixes the following case:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
Traceback (most recent call last):
File "./dotest.py", line 1306, in <module>
setupSysPath()
File "./dotest.py", line 1004, in setupSysPath
if not lldbtest_config.lldbExec:
AttributeError: 'module' object has no attribute 'lldbExec'
```
And with this fix:
```
$ ./dotest.py --executable=~/p/llvm/build_ninja/bin/lldb tools/lldb-mi/
'~/p/llvm/build_ninja/bin/lldb' is not a path to a valid executable
The 'lldb' executable cannot be located. Some of the tests may not be run as a result.
```
llvm-svn: 247256
It often hangs or times out, and obscures issues with other tests.
Just skip it for now (until the FreeBSD test suite is producing
consistent results) so that we can get a buildbot back.
Previous investigation (for failures) in llvm.org/pr18522
llvm-svn: 247190
We had 2 tests named TestCPPBreakpoints.py. If one of those tests
failed, both of them would be reported as failures and contribute
to the failure count. There may be other examples of duplicate
test names, and we should fix those as we find them.
llvm-svn: 247173
See https://llvm.org/bugs/show_bug.cgi?id=24708 for details.
Using '-f FILTER' or unnamed arguments (directories) to dotest.py
will now force no-multiprocessing mode. This stops a bombardment
of test output spam when following the instructions we provide
in a test session trace for rerunning the test.
llvm-svn: 247101
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
Summary:
There were a number of issues about the way I have designed this test originally:
- it relied on single-stepping through large parts of code, which was slow and unreliable
- the threading libraries interfered with the exact thing we wanted to test
For this reason, I have rewritted the test using low-level linux api, which allows the test to be
much more focused. The functionality for other platforms will need to be tested separately.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D12280
llvm-svn: 245838
clang-cl does not yet support C++ exceptions, so these tests will
not even compile.
Re-enabling these tests is tracked by llvm.org/pr24538
llvm-svn: 245747
The test was flaky on the android buildbot, because the 10ms test completed before we got a
chance to interrupt it. I increase the duration to 50ms to hopefully get more consistent results.
llvm-svn: 245555
Summary:
There was a bug in NativeProcessLinux, where doing an instruction-level single-step over the
thread-creation syscall resulted in loss of control over the inferior. This happened because
after the inferior entered the thread-creation maintenance stop, we unconditionally performed a
PTRACE_CONT, even though the original intention was to do a PTRACE_SINGLESTEP. This is fixed by
storing the original state of the thread before the stop (stepping or running) and then
performing the appropriate action when resuming.
I also get rid of the callback in the ThreadContext structure, which stored the lambda used to
resume the thread, but which was not used consistently.
A test verifying the correctness of the new behavior is included.
Reviewers: ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12104
llvm-svn: 245545
the test was failing on android because processing 30 signals involved a lot of round-trips,
which was not possible in the 0.5s default timeout. After the increase the test seems to pass
reliably.
llvm-svn: 245448
Tamas Berghammer