in a session would be silently ignored by the compiler
because the compiler looked at its SourceLocation and
decided it had already handled it.
Also updated the relevant test case.
<rdar://problem/20315447>
llvm-svn: 234330
Summary:
Remove @skipIfGcc from a test in TestSTL as that test passes with GCC
now. Also, mark one of the dsym tests with @skipUnlessDarwin in TestSTL.
Test Plan: dotest.py -C gcc -p TestSTL
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8793
llvm-svn: 234243
Summary:
TestMiCliSupport (among other TestMi*) fails on Linux with
```
IOError: [Errno 2] No such file or directory: 'child.log'
```
Reviewers: clayborg, ki.stfu
Reviewed By: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8843
llvm-svn: 234191
We try to run lldb -P and jump through a bunch of other hoops
to figure out where the Python module is so that we can add its
location to sys.path. The error message printed when this
doesn't work was left over from the time when Mac was the only
platform, so it presented a Mac-specific diagnostic on all
platforms related to the LLDB Framework. This patch prints
a more useful diagnostic when not on Mac that gives a number
of other diagnostic messages to check.
llvm-svn: 234049
verifying that the types from that module don't
override types from DWARF. Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.
<rdar://problem/18805055>
llvm-svn: 234016
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
DWARF types and types from modules can coexist even
if they have the same name and refer to two different
things.
<rdar://problem/18805055>
llvm-svn: 233988
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
On FreeBSD LLDB's triple ends up as e.g. "x86_64-unknown-freebsd10.1"
but getPlatform() consumers expect just the name with no version
number.
llvm-svn: 233705
char is a special type in C++ which can be signed/unsigned and have to
be distinguished both from "signed char" and from "unsigned char". This
test check for this behaviour during the expression evaluation with
different compiler settings.
Differential revision: http://reviews.llvm.org/D8657
llvm-svn: 233678
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
Summary:
This is similar to the change introduced for variable DIEs in r233098. If the
linkage names of functions are missing in the DWARF, then their fully qualified
names (similar to the name that would be got by demangling their linkage name)
is generated using the decl context.
This change fixes TestNamespace when the test case is compiled with GCC, hence
it is enabled for GCC. The test and the test case are also enhanced to cover
variadic functions.
Test Plan: dotest.py -C <clang|gcc> -p TestNamespace
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8623
llvm-svn: 233336
Most expected OS failures or skipped tests are about the target platform on
which the test binary is being run, not the host platform launching the tests.
This changes expectedFailureOS and skipIfPlatform to check against the remote
platform when running remote tests.
Test Plan:
Run ./do_sep.py test suite against a remote target on a different platform and
verify that tests which should be excluded on the remote platform are excluded.
Differential Revision: http://reviews.llvm.org/D8611
llvm-svn: 233311
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
tear down hooks run as part of Base.tearDown(). Some of these
hooks rely on accessing the debugger instance. So although it
looks awkward, we need to call "del self.dbg" after calling
Base.tearDown().
llvm-svn: 233306
Tests derive from TestBase, which derives from Base. In the
test setUp() methods, we always call TestBase.setUp() first and
then call implementation-specific setup. Tear down needs to do
the reverse.
This was causing over 20 failures on Windows, and was the culprit
behind about 80% of the files not being cleaned up after test run.
TestBase.tearDown() is responsible for deleting all targets created
during the test run and without this step, on Windows files will
be locked and cannot be deleted. But TestBase.tearDown() was
calling Base.tearDown() before its own cleanup (i.e. deleting the
targets) and in some cases one of the teardown hooks would be to
call make clean. So make clean would be run before the targets
had been deleted, and fail to remove the files, and subsequently
result in a failed test as well.
llvm-svn: 233284
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
Sean Callanan