9 Commits

Author SHA1 Message Date
Omair Javaid
86e0dd5c1c Xfail failing watchpoint tests on aarch64-linux
Some watchpoint tests fail on aarch64-linux as it lacks support for intalling watchpoints which are not alligned at 8bytes boundary.

Marking them as xfail for now. 

llvm-svn: 269187
2016-05-11 13:57:20 +00:00
Ulrich Weigand
bb00d0b6b2 Support Linux on SystemZ as platform
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform

This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).

There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).

The implementation follows existing platforms in a mostly straightforward
manner.  A couple of things that are different:

- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
  since some registers (access register) reside at offsets in the user area
  that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
  accessing aligned 8-byte blocks in the user area.  Instead, we use a s390
  specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
  allows accessing a whole block of the user area in one go, so in effect
  allowing to treat parts of the user area as register sets.

- SystemZ hardware does not provide any means to implement read watchpoints,
  only write watchpoints.  In fact, we can only support a *single* write
  watchpoint (but this can span a range of arbitrary size).  In LLDB this
  means we support only a single watchpoint.  I've set all test cases that
  require read watchpoints (or multiple watchpoints) to expected failure
  on the platform.  [ Note that there were two test cases that install
  a read/write watchpoint even though they nowhere rely on the "read"
  property.  I've changed those to simply use plain write watchpoints. ]

Differential Revision: http://reviews.llvm.org/D18978

llvm-svn: 266308
2016-04-14 14:28:34 +00:00
Zachary Turner
4a289a93f7 Remove expectedFailureWindows decorator.
expectedFailureWindows is equivalent to using the general
expectedFailureAll decorator with oslist="windows".  Additionally,
by moving towards these common decorators we can solve the issue
of having to support decorators that can be called with or without
arguments.  Once all decorators are always called with arguments,
and this is enforced by design (because you can't specify the condition
you're decorating for without passing an argument) the implementation
of the decorators can become much simpler

Differential Revision: http://reviews.llvm.org/D16936

llvm-svn: 260134
2016-02-08 19:34:59 +00:00
Zachary Turner
9a1a2946af Move the rest of the tests over to using the new decorator module.
llvm-svn: 259838
2016-02-04 23:04:17 +00:00
Zachary Turner
7a5382de82 Move some of the common decorators to decorators.py.
This doesn't attempt to move every decorator.  The reason for
this is that it requires touching every single test file to import
decorators.py.  I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.

llvm-svn: 259807
2016-02-04 18:03:01 +00:00
Tamas Berghammer
0ecdae1bdc Merge ENABLE_THREADS and ENABLE_STD_THREADS markers
Both of these markers are used in the test suit for annotating when a
test needs multi threaded support. Previously they had slightly
different meening but they converged to the point where they are used
interchangably. This CL removes the ENABLE_STD_THREADS one to simplify
the test suite and avoid some confusion.

Differential revision: http://reviews.llvm.org/D15498

llvm-svn: 255641
2015-12-15 12:11:00 +00:00
Zachary Turner
19474e1801 Remove use_lldb_suite from the package, and don't import it anymore.
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries.  Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this.  Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.

To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`

llvm-svn: 251963
2015-11-03 19:20:39 +00:00
Zachary Turner
95c453a221 Tighten up sys.path, and use absolute imports everywhere.
For convenience, we had added the folder that dotest.py was in
to sys.path, so that we could easily write things like
`import lldbutil` from anywhere and any test.  This introduces
a subtle problem when using Python's package system, because when
unittest2 imports a particular test suite, the test suite is detached
from the package.  Thus, writing "import lldbutil" from dotest imports
it as part of the package, and writing the same line from a test
does a fresh import since the importing module was not part of
the same package.

The real way to fix this is to use absolute imports everywhere.  Instead
of writing "import lldbutil", we need to write "import
lldbsuite.test.util".  This patch fixes up that and all other similar
cases, and additionally removes the script directory from sys.path
to ensure that this can't happen again.

llvm-svn: 251886
2015-11-03 02:06:18 +00:00
Zachary Turner
c432c8f856 Move lldb/test to lldb/packages/Python/lldbsuite/test.
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package.  This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).

llvm-svn: 251532
2015-10-28 17:43:26 +00:00