15 Commits

Author SHA1 Message Date
Jim Ingham
19c28eee46 Working through testcases, converting to run_to_source_breakpoint.
llvm-svn: 307287
2017-07-06 18:06:25 +00:00
Kate Stone
b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort.  Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit.  The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

    find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
    find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit.  There are alternatives available that will attempt
to look through this change and find the appropriate prior commit.  YMMV.

llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Pavel Labath
ce57a33e58 Bump up TestCallWithTimeout timeout
Still a bit flaky on remote targets. Trying a larger bump this time. :/

llvm-svn: 280477
2016-09-02 09:25:42 +00:00
Pavel Labath
613cce835f Bump up timeout in TestCallWithTimeout
remote targets need a bit more time to get their act together

llvm-svn: 274762
2016-07-07 15:45:57 +00:00
Pavel Labath
a24427533f Bump up timeout in TestCallWithTimeout
Expression very rarely (linux buildbot, build 13907) completed before we managed to interrupt it.

llvm-svn: 267554
2016-04-26 13:37:24 +00:00
Todd Fiala
3249911439 mark TestCallWithTimeout.py XFAIL on macosx.
This test is failing on the CI but not locally for me.  Needs
investigation.

tracked by:
https://llvm.org/bugs/show_bug.cgi?id=27182

llvm-svn: 265175
2016-04-01 18:42:45 +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
Pavel Labath
916895073e Remove flaky annotation for TestCallWithTimeout on linux
The test has passed last 100 runs of the buildbot.

llvm-svn: 259368
2016-02-01 16:50:28 +00:00
Pavel Labath
19da1f16c2 Recommit "Fix race during process interruption"
This is a resubmit of r254403, see that commit's message for context. This fixes an issue in the
original commit, where we would incorrectly interrupt the process if the interrupt request came
just as we were about to send the stopped event to the public.

llvm-svn: 254902
2015-12-07 12:36:52 +00:00
Pavel Labath
00fea63627 Revert "Fix race during process interruption"
The android buildbot gets quite flaky after this change. I'm reverting it while I investigate.

llvm-svn: 254430
2015-12-01 17:59:56 +00:00
Pavel Labath
df55f522bd Fix race during process interruption
Summary:
The following situation was occuring in TestAttachResume:
- we did a "continue" from a breakpoint (which involves a private start-stop to step over the
  breakpoint)
- after receiving the stop-reply from the step-over, we issue a "detach" (which requires a
  process interrupt)
- at this moment, the public state is "running", private state is "about-to-be-stopped" (the
  stopped event was broadcast, but it was not received yet)
- StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt
  request to the private thread
- private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the
  process plugin to stop (via Halt())
- process plugin says it has nothing to do as the process is already stopped
- private thread shrugs and carries on. receives the stop event, restores the breakpoint and
  resumes the process.
- after a while, the public thread times out and says it failed to stop the process

This patch does the following:
- splits Halt() into two functions, private and public, their usage depends on the context
  - public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop
    event
  - HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the
    next stop event comes it sets the interrupt flag on it.
- removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away
- removes the m_currently_handling_event hack, as the new Halt() does not need it
- adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed
  because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take
  it away from him.

Reviewers: clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 254403
2015-12-01 11:28:47 +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