Summary:
The decorator @expectedFailureGcc was at the wrong place skipping this
test all together. This patch removes it and adds skipIfGcc at the right
place.
Test Plan: dotest.py -C <gcc|clang> -p TestPluginCommands
Reviewers: chying, chaoren
Reviewed By: chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9010
llvm-svn: 234821
Summary:
`-lpthread` was removed for `g++ -std=c++11` on Linux due to llvm.org/pr21553,
but the original issue doesn't seem to be reproducible anymore. Even if it were,
it had nothing to do with compiling inferiors.
Reviewers: sbest, sivachandra, chying
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8991
llvm-svn: 234770
Summary:
This is to get the bots to go green while a robust solution to fix these
tests is worked out.
Reviewers: chaoren, tberghammer, clayborg
Reviewed By: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8947
llvm-svn: 234625
This covers most of rdar://20490076, but leaves one corner case still open - namely the case where we try to have arguments of the form foo\ bar (unquoted, but slashed) go through argdumper
llvm-svn: 234554
The OperatingSystem plug-ins allow code to detect threads in memory and then say "memory thread 0x11111" is backed by the actual thread 1.
You can then single step these virtual threads. A problem arose when thread specific breakpoints were used during thread plans where we would say "set a breakpoint on thread 0x11111" and we would hit the breakpoint on the real thread 1 and the thread IDs wouldn't match and we would get rid of the "stopped at breakpoint" stop info due to this mismatch. Code was added to ensure these events get forwarded and thus allow single stepping a memory thread to work correctly.
Added a test case for this as well.
<rdar://problem/19211770>
llvm-svn: 234364
Summary:
Updated test to reflect that Linux and Darwin behave the same now.
Removed @expectedFailureLinux for passing tests.
Test Plan: run tests
Reviewers: clayborg, sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8678
llvm-svn: 233989
There was a lot of code that was checking "if self.getPlatform() == 'darwin'" which is not correct. I fixed this by adding a:
lldbtest.platformIsDarwin()
which returns true if the current platform's OS is "macosx", "ios" or "darwin". These three valid darwin are now returned by a static function:
lldbtest.getDarwinOSTriples()
Fixed up all places that has 'if self.getPlatform() == "darwin":' with "if self.platformIsDarwin()" and all instances of 'if self.getPlatform() != "darwin":' with "if not self.platformIsDarwin()". I also fixed some darwin decorator functions to do the right thing as well.
llvm-svn: 233933
These test cases check if they are able to read registers after the
inferior is crashed. Previously they did it with reading the eax
register what is only available on i386 and x86_64. Thic CL add code to
do the check based on the target architecture (currently i386, x86_64
and aarch64 is supported)
Differential revision: http://reviews.llvm.org/D8702
llvm-svn: 233907
Uses target platform when determining which platform specific behavior to use
or expect in tests. TestHelp.py was unchanged because this is asserting
behavior of the local lldb binary.
Test Plan:
Run tests on different remote os. Several previously failing tests now pass:
TestArrayTypes.py
TestInferiorChanged.py
TestInferiorCrashing.py
TestIvarProtocols.py
TestProcessIO.py
TestPublicAPIHeaders.py
TestRecursiveInferior.py
Differential Revision: http://reviews.llvm.org/D8747
llvm-svn: 233805
Removed expectedFailureLinux from failures that I was unable to
reproduce, updated and improved some other comments near XFAIL tests
Differential Revision: http://reviews.llvm.org/D8676
llvm-svn: 233716
Summary: There is an extra eStateConnected before eStateRunning with remote.
Reviewers: clayborg, ovyalov
Reviewed By: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8714
llvm-svn: 233670
Adds @skipIfPlatform and @skipUnlessPlatform decorators which will skip if /
unless the target platform is in the provided platform list.
Test Plan:
ninja check-lldb shows no regressions.
When running cross platform, tests which cannot run on the target platform are
skipped.
Differential Revision: http://reviews.llvm.org/D8665
llvm-svn: 233547
Previously we were using teardown hooks in these two instances to
shutdown processes. TestBase already deletes all targets in its
own teardown, which will kill processes, so these steps weren't
necessary.
llvm-svn: 233308
This patch fixes the following:
```
1: test_attach_to_process_by_id_with_dsym (TestProcessAttach.ProcessAttachTestCase)
Test attach by process id ... ok
2: test_attach_to_process_by_id_with_dwarf (TestProcessAttach.ProcessAttachTestCase)
Test attach by process id ... ok
3: test_attach_to_process_by_name_with_dsym (TestProcessAttach.ProcessAttachTestCase)
Test attach by process name ... FAILURE
4: test_attach_to_process_by_name_with_dwarf (TestProcessAttach.ProcessAttachTestCase)
Test attach by process name ... FAILURE
======================================================================
FAIL: test_attach_to_process_by_name_with_dsym (TestProcessAttach.ProcessAttachTestCase)
Test attach by process name
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 462, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/TestProcessAttach.py", line 35, in test_attach_to_process_by_name_with_dsym
self.process_attach_by_name()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/TestProcessAttach.py", line 79, in process_attach_by_name
self.runCmd("process attach -n s" + exe_name)
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2008, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process attach -n sProcessAttach' returns successfully
Config=x86_64-clang
======================================================================
FAIL: test_attach_to_process_by_name_with_dwarf (TestProcessAttach.ProcessAttachTestCase)
Test attach by process name
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 479, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/TestProcessAttach.py", line 41, in test_attach_to_process_by_name_with_dwarf
self.process_attach_by_name()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/TestProcessAttach.py", line 79, in process_attach_by_name
self.runCmd("process attach -n s" + exe_name)
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2008, in runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process attach -n sProcessAttach' returns successfully
Config=x86_64-clang
----------------------------------------------------------------------
```
Failure-x86_64-clang-TestProcessAttach.ProcessAttachTestCase.test_attach_to_process_by_name_with_dsym.log:
```
[...]
runCmd: process attach -n ProcessAttach
runCmd failed!
error: attach failed: more than one process named ProcessAttach:
PID PARENT USER TRIPLE ARGUMENTS
====== ====== ========== ======================== ============================
43752 43680 IliaK x86_64-apple-macosx /Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/ProcessAttach
43663 1 IliaK x86_64-apple-macosx /Users/IliaK/p/llvm/tools/lldb/test/functionalities/process_attach/ProcessAttach
[...]
```
llvm-svn: 233272
% lldb /bin/echo
(lldb) r 1 2 3
(lldb) r
You get "1", "2", and "3" as arguments in the next re-run when no args are specified. This is behavior we do to match what GDB did and we need to test that we don't regress on it.
<rdar://problem/20300941>
llvm-svn: 233236
The previous implementation only read out the first element of the
underlying storage array. Because of it only the first 32 (on x86) or
the first 64 (on x86_64) element was displayed.
Differential revision: http://reviews.llvm.org/D8585
llvm-svn: 233179
Since ClangASTSource::layoutRecordType() was overriding a virtual
function in the base, this was inadvertently causing a new method
to be introduced rather than an override. To fix this all method
signatures are changed back to taking DenseMaps, and the `override`
keyword is added to make sure this type of error doesn't happen
again.
To keep the original fix intact, which is that fields and bases
must be added in offset order, the ImportOffsetMap() function
now copies the DenseMap into a vector and then sorts the vector
on the value type (e.g. the offset) before iterating over the
sorted vector and inserting the items.
llvm-svn: 233099
Prior to this patch, we would try to synthesize class types by
iterating over a DenseMap of FieldDecls and adding each one to
a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic
ordering of the elements, this would not add the fields in
FieldOffset order, but rather in some random order determined by
the memory layout of the DenseMap.
This patch fixes the issue by changing DenseMaps to vectors. The
ability to lookup a value in the DenseMap was hardly being used,
and where it is sufficient to do a vector lookup.
Differential Revision: http://reviews.llvm.org/D8512
llvm-svn: 233090
To run tests against a different target platform many extra compiler flags are
needed to specify sysroot, include dirs, etc. The environment variable
CFLAGS_EXTRAS seems suited for this purpose except that several Makefiles
clobber the current flags. This change modifies all of these to add to
CFLAGS_EXTRAS instead.
Test Plan:
Verify no regressions in ninja check-lldb.
Run tests using CFLAGS_EXTRAS to specify cross compilation flags for a different
target running lldb-server platform.
Differential Revision: http://reviews.llvm.org/D8559
llvm-svn: 233066
The time/date strings (like "6pm April 10, 1985") are interpreted as a local time but CFDateGetAbsoluteTime() returns time in UTC. It caused a problem when local time was UTC+0100 or more (0200, 0300 etc.):
```
======================================================================
FAIL: test_nsdate_with_dsym_and_run_command (TestDataFormatterObjC.ObjCDataFormatterTestCase)
Test formatters for NSDate.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 462, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 157, in test_nsdate_with_dsym_and_run_command
self.appkit_tester_impl(self.buildDsym,self.nsdate_data_formatter_commands)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 34, in appkit_tester_impl
commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 475, in nsdate_data_formatter_commands
substrs = ['1985-04','2011-01'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2146, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '2011-01' returns expected result
Config=x86_64-clang
======================================================================
FAIL: test_nsdate_with_dwarf_and_run_command (TestDataFormatterObjC.ObjCDataFormatterTestCase)
Test formatters for NSDate.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 479, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 163, in test_nsdate_with_dwarf_and_run_command
self.appkit_tester_impl(self.buildDwarf,self.nsdate_data_formatter_commands)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 34, in appkit_tester_impl
commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 475, in nsdate_data_formatter_commands
substrs = ['1985-04','2011-01'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2146, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '2011-01' returns expected result
Config=x86_64-clang
```
llvm-svn: 232946
Summary:
GCC does not emit some DWARF required for the simplified formatter
to work. A workaround for it has been incorporated in the formatter.
The corresponding test TestDataFormatterStdMap has also been enabled
for GCC.
Test Plan: dotest.py -C <clang|gcc> -p TestDataFormatterStdMap
Reviewers: clayborg, vharron, granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8424
llvm-svn: 232678
Summary:
This test now passes for Clang and GCC. I do not know why it was
disabled for GCC with link to a bug which should not have had an
effect on this test.
Test Plan: dotest.py -C gcc -p TestDataFormatterStdIterator
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8396
llvm-svn: 232552
Summary:
The existing formatter in C++ has been removed as it was not being used.
The associated test TestDataFormatterStdVBool.py has been enabled for
both Clang and GCC on Linux.
Test Plan: dotest.py -p TestDataFormatterStdVBool
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8390
llvm-svn: 232548
Summary:
This test should have been enabled along with
7181dae1248cc1b03505cca1b7c6e3dfeffefc0a, but since the test was
actually crashing, I thought it was a much deeper problem. Turns out,
all I had to do was to add "-fno-limit-debug-info" when compiling
the test case.
The test is still skipped when the testcase is compiled with GCC.
Test Plan: dotest.py -p TestDataFormatterStdMap
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8364
llvm-svn: 232432
Summary:
After 7181dae1248cc1b03505cca1b7c6e3dfeffefc0a, this test progresses
much further but crashes. Will skip this test while I fix this properly.
Test Plan: dotest.py -p TestDataFormatterStdMap
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8361
llvm-svn: 232403
The test does the following:
1 - runs a program to main without the OS plug-in and verifies no OS threads are in the process
2 - loads the OS plug-in and verifies the 3 OS plug-in threads are now in the current process
3 - verify the register contents of each thread that shows up
4 - unload the python OS plug-in and verify that the OS threads are gone.
llvm-svn: 232401
Summary:
Also, change its return type to size_t to match the return types of
its callers.
With this change, std::vector and std::list data formatter tests
pass on Linux (when using libstdc++) with clang as well as with gcc.
These tests have also been enabled in this patch.
Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList>
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8337
llvm-svn: 232399
This fixes tests on clang-3.4
AFAICT, these flags have the same affect and -fstandalone-debug wasn't
added until after clang-3.4
Committed to try to fix buildbot
Differential Revision: http://reviews.llvm.org/D8347
llvm-svn: 232326
The value of some_values (pointer) expeced to start by 0x0 but nothing
requires that the first digit of the address be '0'.
This CL change the expectation to check only for a value starting with 0x.
llvm-svn: 232163
