Instead of opening the file in unicode mode, we need only encode
data which potentially has non-ASCII characters as UTF8 before
writing. This should work across both Python versions, and is
also far simpler than anything else discussed.
llvm-svn: 258969
* basestring is not a thing anymore. Must use `six.string_types`.
* Must use from __future__ import print_function in every new test
file.
llvm-svn: 258967
Previously the logic of skipIf and expectedFailure were 99%
the same, but they took different sets of arguments since they
were maintained separately, and had slightly differences in
their behavior. This makes everything consistent, there is now
only one real implementation, and the previous ones are changed
to use the single master implementation.
llvm-svn: 258966
SUMMARY:
Get the load address for the address given by symbol and function.
Earlier, this was done for function only, this patch does it for symbol too.
This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change.
Reviewers: clayborg
Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16049
llvm-svn: 258919
Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception. The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.
llvm-svn: 258759
Since Unicode support is different in Py2 and Py3, Py3 was throwing
exceptions about being unable to decode the file with the default
encoding.
llvm-svn: 258588
Unfortunately, this turns out not to be working on the lldb-server tests, as there the server is
started in a different way. Since this was a bit of a hack to start with, I am removing it until
I can solve the problem more holistically.
llvm-svn: 258501
Summary:
We already have the ability to collect the server logs when doing local debugging. This enables
the collection of remote logs as well. This relies on specifying a relative path "server.log" for
LLDB_DEBUGSERVER_LOG_FILE when starting remote platform. Since we always set the platform working
directory to a fresh folder to avoid conflicts, the actual file path will always be different and
we can pick the logs up from there.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16322
llvm-svn: 258414
This does not work and causes the class to be silently skipped, which is a bad idea. This makes
sure it cannot happen accidentaly. I've played with the idea of actually making the decorator
work at class level, but it proved too magic to do at this moment.
llvm-svn: 258048
Updated expectedFailureLinux decorator to reflect architecture
Marked some triaged failures as xfails on arm with updated expectedFailureLinux decorator
Differential revision: http://reviews.llvm.org/D15893
llvm-svn: 257405
Summary:
This removes the old logic for rerunning flaky tests. The new test runners will take care of
rerunning failing tests.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15855
llvm-svn: 256824
Summary:
This adds ability to mark test that do not complete due to hangs, crashes, etc., as "expected",
to avoid flagging the build red for a known problem. Functionally, this extends the scope of the
existing expectedFailureXXX decorators to cover these states as well. Once this is in, I will
start replacing the magic list of failing tests in dosep.py with our regular annotations which
should hopefully make code simpler.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15530
llvm-svn: 255763
Summary:
Previously the add_test_categories would simply overwrite the current set of categories for a
method. This change makes the decorator truly "add" categories, by extending the current set of
categories instead of replacing it.
To do this, I have:
- replaced the getCategories() property on a method (which was itself a method), with a simple
list property "categories". This makes add_test_categories easier to implement, and test
categories isn't something which should change between calls anyway.
- rewritten the getCategoriesForTest function to merge method categories with the categories of
the test case. Previously, it would just use the method categories if they were present. I have
also greatly simplified this method. Originally, it would use a lot of introspection to enable
it being called on various types of objects. Based on my tests, it was only ever being called
on a test case. The new function uses much less introspection then the preivous one, so we
should easily catch any stray uses, if there are any, as they will generate exceptions now.
Reviewers: zturner, tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15451
llvm-svn: 255493
This will be used in a future change to support rerunning flakey tests
that hit a test result isue in a low-load, single worker test runner phase.
This is implemented as an additive-style event rather than being
evaluated and added to the start_test event because the decorator code
only runs after the start_test event is created and sent. i.e.
LLDBTestResult.startTest() runs before the test method decorators run.
llvm-svn: 255351
Summary: NetBSD is like FreeBSD and Linux in these routines.
Reviewers: clay.chang, tfiala, emaste, joerg
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D15374
llvm-svn: 255308
This seems to be a legacy relic from days gone by where the
remote test suite runner operated completely differently than it
does today. git blames and comments traced this functionality
back to about 2012, and nobody seems to know anything about it
now.
llvm-svn: 255060
The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.
The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.
Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.
This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.
Differential revision: http://reviews.llvm.org/D14952
llvm-svn: 255016
This moves all the global variables into a separate module called
`configuration`. This has a number of advantages:
1. Configuration data is centrally maintained so it's easy to get
a high level overview of what configuration data the test suite
makes use of.
2. The method of sharing configuration data among different parts
of the test suite becomes standardized. Previously we would
put some things into the `lldb` module, some things into the
`lldbtest_config` module, and some things would not get shared.
Now everything is shared through one module and is available to
the entire test suite.
3. It opens the door to moving some of the initialization code into
the `configuration` module, simplifying the implementation of
`dotest.py`.
There are a few stragglers that didn't get converted over to using
the `configuration` module in this patch, because it would have grown
the size of the patch unnecessarily. This includes everything
currently in the `lldbtest_config` module, as well as the
`lldb.remote_platform` variable. We can address these in the future.
llvm-svn: 254982
Summary: This is used in tests.
Reviewers: emaste, tfiala, clayborg
Subscribers: zturner, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D15065
llvm-svn: 254853
Summary:
This reverts commit 251965377bdfb6227eea42c12a792c059e4e8a4b
as a test marked "skipIf(compiler='gcc')" runs when testing with GCC.
Reviewers: amccarth
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14852
llvm-svn: 253631
This patch fixes two issues:
1) Popen needs to be used with universal_newlines=True by default.
This elicits automatic decoding from bytes -> string in Py3,
and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
did not work correctly when the length of the string was 0,
indicating an error. In this case we would try to construct a
string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
Windows that was actually broken, because the test was written
such that the assertion was never even getting checked, so it
passed by default. So we additionally fix this test to also
fail if the method errors. By fixing this test it's now broken
on Windows, so we also xfail it.
llvm-svn: 253487
Current versions of SWIG have a bug with Python 3 that causes
Python to assert when iterating over a generator. This patch
skips the test for the right combination of Python version and
SWIG version. I'm attempting to upstream a patch to SWIG to
fix this in a subsequent as-of-yet unreleased version, but
I don't know how long that will take.
llvm-svn: 253273
This is unsupported in Python 3. This could also have been fixed
by using "wb" instead of "w", but it doesn't seem like writing the
session log absolutely *needs* to be unbuffered.
llvm-svn: 252381
We tried implementing something akin to a conditionalExpectedFailure
decorator for unittest2. We did this by making use of some
implementation details of the unittest2 module. In an effort to make
this work with unittest, this patch removes the reliance on the
implementation details. I have a hard time wrapping my head around
how this all works with the deeply nested decorators, but the spirit
of the patch here is to do do the following: If the condition function
is true, use the original unittest2.expectedFailure decorator. Otherwise
don't use any decorator, just call the test function.
Differential Revision: http://reviews.llvm.org/D14406
Reviewed By: tberghammer, labath
llvm-svn: 252326
Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.
When absolute imports are enabled, the import system changes in
a couple of ways:
1) The `import foo` syntax will *only* search sys.path. If `foo`
isn't in sys.path, it won't be found. Period. Without absolute
imports, the import system will also search the same directory
that the importing file resides in, so that you can easily
import from the same folder.
2) From inside a package, you can use a dot syntax to refer to higher
levels of the current package. For example, if you are in the
package lldbsuite.test.utility, then ..foo refers to
lldbsuite.test.foo. You can use this notation with the
`from X import Y` syntax to write intra-package references. For
example, using the previous locationa s a starting point, writing
`from ..support import seven` would import lldbsuite.support.seven
Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.
See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.
Differential Revision: http://reviews.llvm.org/D14342
Reviewed By: Todd Fiala
llvm-svn: 252191
