Python 3 - Turn on absolute imports, and fix existing imports.
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
2015-11-05 19:22:28 +00:00
|
|
|
# System modules
|
2019-12-20 15:11:49 +01:00
|
|
|
import os
|
2015-02-02 22:12:39 +00:00
|
|
|
import sys
|
Python 3 - Turn on absolute imports, and fix existing imports.
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
2015-11-05 19:22:28 +00:00
|
|
|
|
|
|
|
# LLDB Modules
|
|
|
|
import lldb
|
|
|
|
from .lldbtest import *
|
|
|
|
from . import lldbutil
|
2020-08-05 15:20:53 -07:00
|
|
|
from lldbsuite.test.decorators import *
|
Python 3 - Turn on absolute imports, and fix existing imports.
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
2015-11-05 19:22:28 +00:00
|
|
|
|
2023-05-25 08:48:57 -07:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
@skipIfRemote
|
2024-03-13 15:16:15 -05:00
|
|
|
@add_test_categories(["pexpect"])
|
2020-08-28 11:41:07 -07:00
|
|
|
class PExpectTest(TestBase):
|
|
|
|
NO_DEBUG_INFO_TESTCASE = True
|
|
|
|
PROMPT = "(lldb) "
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
def expect_prompt(self):
|
|
|
|
self.child.expect_exact(self.PROMPT)
|
2015-02-02 22:12:39 +00:00
|
|
|
|
[lldb/driver] Fix SIGTSTP handling
Our SIGTSTP handler was working, but that was mostly accidental.
The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).
Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.
Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.
This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
the thread which is running the handler
This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.
I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.
Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
|
|
|
def launch(
|
|
|
|
self,
|
|
|
|
executable=None,
|
|
|
|
extra_args=None,
|
|
|
|
timeout=60,
|
2022-05-18 11:35:20 -07:00
|
|
|
dimensions=None,
|
|
|
|
run_under=None,
|
|
|
|
post_spawn=None,
|
2023-09-13 20:08:05 -07:00
|
|
|
encoding=None,
|
2022-05-18 11:35:20 -07:00
|
|
|
use_colors=False,
|
|
|
|
):
|
2023-09-13 20:28:28 -07:00
|
|
|
# Using a log file is incompatible with using utf-8 as the encoding.
|
|
|
|
logfile = (
|
|
|
|
getattr(sys.stdout, "buffer", sys.stdout)
|
|
|
|
if (self.TraceOn() and not encoding)
|
|
|
|
else None
|
|
|
|
)
|
2016-01-27 18:49:25 +00:00
|
|
|
|
[lldb/driver] Fix SIGTSTP handling
Our SIGTSTP handler was working, but that was mostly accidental.
The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).
Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.
Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.
This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
the thread which is running the handler
This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.
I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.
Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
|
|
|
args = []
|
|
|
|
if run_under is not None:
|
|
|
|
args += run_under
|
2022-05-18 11:35:20 -07:00
|
|
|
args += [lldbtest_config.lldbExec, "--no-lldbinit"]
|
|
|
|
if not use_colors:
|
2022-05-19 14:47:04 -07:00
|
|
|
args.append("--no-use-colors")
|
2020-08-28 11:41:07 -07:00
|
|
|
for cmd in self.setUpCommands():
|
2022-05-18 21:12:15 -07:00
|
|
|
if "use-color false" in cmd and use_colors:
|
|
|
|
continue
|
|
|
|
args += ["-O", cmd]
|
2020-08-28 11:41:07 -07:00
|
|
|
if executable is not None:
|
|
|
|
args += ["--file", executable]
|
|
|
|
if extra_args is not None:
|
|
|
|
args.extend(extra_args)
|
2019-12-20 15:11:49 +01:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
env = dict(os.environ)
|
2021-09-14 15:13:51 +02:00
|
|
|
env["TERM"] = "vt100"
|
|
|
|
env["HOME"] = self.getBuildDir()
|
2019-12-20 15:11:49 +01:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
import pexpect
|
2023-05-25 08:48:57 -07:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
self.child = pexpect.spawn(
|
[lldb/driver] Fix SIGTSTP handling
Our SIGTSTP handler was working, but that was mostly accidental.
The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).
Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.
Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.
This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
the thread which is running the handler
This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.
I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.
Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
|
|
|
args[0],
|
|
|
|
args=args[1:],
|
|
|
|
logfile=logfile,
|
2020-08-28 11:41:07 -07:00
|
|
|
timeout=timeout,
|
|
|
|
dimensions=dimensions,
|
|
|
|
env=env,
|
2023-09-13 20:08:05 -07:00
|
|
|
encoding=encoding,
|
2020-08-28 11:41:07 -07:00
|
|
|
)
|
2022-03-22 14:52:02 +01:00
|
|
|
self.child.ptyproc.delayafterclose = timeout / 10
|
|
|
|
self.child.ptyproc.delayafterterminate = timeout / 10
|
[lldb/driver] Fix SIGTSTP handling
Our SIGTSTP handler was working, but that was mostly accidental.
The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).
Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.
Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.
This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
the thread which is running the handler
This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.
I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.
Differential Revision: https://reviews.llvm.org/D120320
2022-02-22 14:25:39 +01:00
|
|
|
|
|
|
|
if post_spawn is not None:
|
|
|
|
post_spawn()
|
2020-08-28 11:41:07 -07:00
|
|
|
self.expect_prompt()
|
|
|
|
for cmd in self.setUpCommands():
|
2022-05-18 21:12:15 -07:00
|
|
|
if "use-color false" in cmd and use_colors:
|
|
|
|
continue
|
|
|
|
self.child.expect_exact(cmd)
|
|
|
|
self.expect_prompt()
|
2020-08-28 11:41:07 -07:00
|
|
|
if executable is not None:
|
|
|
|
self.child.expect_exact("target create")
|
|
|
|
self.child.expect_exact("Current executable set to")
|
dotest: improvements to the pexpect tests
Summary:
While working on r370054, i've found it frustrating that the test output
was compeletely unhelpful in case of failures. Therefore I've decided to
improve that. In this I reuse the PExpectTest class, which was one of
our mechanisms for running pexpect tests, but which has gotten orhpaned
in the mean time.
I've replaced the existing send methods with a "expect" method, which
I've tried to design so that it has a similar interface to the expect
method in regular non-pexpect dotest tests (as it essentially does
something very similar). I've kept the ability to dump the transcript of
the pexpect communication to stdout in the "trace" mode, as that is a
very handy way to figure out what the test is doing. I've also removed
the "expect_string" method used in the existing tests -- I've found this
to be unhelpful because it hides the message that would be normally
displayed by the EOF exception. Although vebose, this message includes
some important information, like what strings we were searching for,
what were the last bits of lldb output, etc. I've also beefed up the
class to automatically disable the debug info test duplication, and
auto-skip tests when the host platform does not support pexpect.
This patch ports TestMultilineCompletion and TestIOHandlerCompletion to
the new class. It also deletes TestFormats as it is not testing anything
(definitely not formats) -- it was committed with the test code
commented out (r228207), and then the testing code was deleted in
r356000.
Reviewers: teemperor, JDevlieghere, davide
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D66954
llvm-svn: 370449
2019-08-30 09:07:42 +00:00
|
|
|
self.expect_prompt()
|
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
def expect(self, cmd, substrs=None):
|
|
|
|
self.assertNotIn("\n", cmd)
|
2020-11-05 13:41:26 +01:00
|
|
|
# If 'substrs' is a string then this code would just check that every
|
|
|
|
# character of the string is in the output.
|
|
|
|
assert not isinstance(substrs, str), "substrs must be a collection of strings"
|
2021-02-12 08:51:43 +01:00
|
|
|
|
|
|
|
self.child.sendline(cmd)
|
2020-08-28 11:41:07 -07:00
|
|
|
if substrs is not None:
|
|
|
|
for s in substrs:
|
|
|
|
self.child.expect_exact(s)
|
|
|
|
self.expect_prompt()
|
|
|
|
|
|
|
|
def quit(self, gracefully=True):
|
|
|
|
self.child.sendeof()
|
|
|
|
self.child.close(force=not gracefully)
|
|
|
|
self.child = None
|
[lldb] Display autosuggestion part in gray if there is one possible suggestion
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
2020-08-12 12:54:28 +02:00
|
|
|
|
2020-08-28 11:41:07 -07:00
|
|
|
def cursor_forward_escape_seq(self, chars_to_move):
|
|
|
|
"""
|
|
|
|
Returns the escape sequence to move the cursor forward/right
|
|
|
|
by a certain amount of characters.
|
|
|
|
"""
|
|
|
|
return b"\x1b\[" + str(chars_to_move).encode("utf-8") + b"C"
|