tests when targetting a device. Add an include to
safe-to-call-func to work around a modules issue with
a certain combination of header files. Add rules for
Darwin systems to ad-hoc codesign binaries that the
testsuite builds.
llvm-svn: 344635
Summary:
The test suite has often unnecessary trailing whitespace, and sometimes
unnecessary trailing lines or a missing final new line. This patch just strips
trailing whitespace/lines and adds missing newlines at the end.
Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits
Differential Revision: https://reviews.llvm.org/D49943
llvm-svn: 338171
LLDB doesn't use this packet so we never hit this, but it looks like
some other projects talk to debugserver and are hitting an assert
(https://github.com/derekparker/delve/issues/1015).
We had an off by 1 in the accounting of the FPU structure sizes.
I added a test that basically just check that 'g' doesn't return
an error (currently it assert in debug builds). I didn't make
it an lldb-server test because it looks like lldb-server doesn't
implement the g packet.
llvm-svn: 331004
When I merged the 2 codepaths that return an OS type, I hade
checked that the places accepting 'iphoneos' would also accept
'ios', but then I got it backwards and return 'iphoneos'.
We use this value to build triples, and there 'iphoneos' is
invalid.
This also makes the test slightly simpler.
llvm-svn: 330877
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.
The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.
Reviewers: jasonmolenda, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D45298
llvm-svn: 329374
Summary: PPC64's auxvec has a special key that must be ignored.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43771
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 328486
Summary:
On PPC64, the tested functions were being entered through their local entry point, while the tests expected the program to stop at the function start address, that, for PPC64, corresponds to the global entry point.
To fix the issue, the test program was modified to call the functions to be tested through function pointers, which, on PPC64, force the calls through the global entry point, while not affecting the test on other platforms.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43768
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327013
Summary:
- reg_nums were missing the end marker entry
- marked FP test to be skipped for ppc64
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: alexandreyy, lbianc, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D43767
Patch by Leandro Lupori <leandro.lupori@gmail.com>
llvm-svn: 326775
This test contained a copy of the inferior used by most of llgs test.
This was done to enable better paralelization, but now it's irrelevant.
llvm-svn: 326218
Summary:
These were not being flaky, but they're still making the tree dirty.
These tests were using lldbutil.append_to_process_working_directory to
derive the file path so I fix them by modifying the function to return
the build directory for local tests.
Technically, now the path returned by this function does not point to
the process working directory for local tests, but I think it makes
sense to keep the function name, as I think we should move towards
launching the process in the build directory (and I intend to change
this for the handful of inferiors that actually care about their PWD,
for example because they need to create files there).
Reviewers: davide, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43506
llvm-svn: 325690
The test was generating long unix socket names, and the addition of a
new folder in the previous patch pushed it over the limit (although
linux has a fairly generous limit for path names, this does not apply to
unix sockets).
Modify the test to use a shorter name instead.
llvm-svn: 325340
Since the ipv6 patch, we've experienced occasional flakyness in
lldb-server tests. This was due to the fact that lldb-server was trying
to listen on both v4 and v6 localhost sockets (and consider it a success
if at least one of them succeeded), while the test framework was only
trying to connect to the v4 one.
This change makes sure lldb-server only listens on the v4 socket.
llvm-svn: 316391
Normal customer devices won't be able to run these tests, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314132
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314038
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
The step count depends on code generated by compiler (GCC/Clang).
It will also vary for different MIPS arch variant. Hence skipping these test for MIPS.
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305383
Summary:
'arch' is a valid qHostInfo key, but the unit
test for qHostInfo did not include it in the set of possible keys.
Reviewers: tfiala, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32711
llvm-svn: 302260
Summary:
These classes existed only because of the GetName() static function,
which can be moved to a more natural place anyway. I move the linux
version to NativeProcessLinux (and get rid of ProcFileReader), the
freebsd version to ProcessFreeBSD (and fix a bug where it was using the
current process ID, instead of the inferior pid), and remove the NetBSD
version (which was probably incorrect anyway, as it assumes the current
process instead of the inferior.
I also add an llgs test to that verifies thread names are read
correctly.
Reviewers: zturner, krytarowski, emaste
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30981
llvm-svn: 298058
this test was using the VPATH hack to avoid having a copy of the
inferior source code. This makes the test fail if in happens to run
concurrently with a test in the parent folder. Fix that by moving it up
to the parent.
llvm-svn: 296741
Summary:
Native Thread ID is retrieved with _lwp_self() on NetBSD.
The returned value is of type int32_t, but for consistency with other Operating Systems cast it to uint64_t.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, labath, clayborg, emaste
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30374
llvm-svn: 296360
Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.
Reviewers: jmajors, labath
Subscribers: danalbert, srhines, emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 296101
Summary:
The server was no longer sending the thread PCs the way the client
expected them.
I changed the server to send them back as a threadstop info field,
similar to the Apple version of the server.
I also changed the client to look for them there, before querying the
server.
I added a test to ensure the server doesn't stop sending them.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D28880
Author: Jason Majors
llvm-svn: 292611
It turns out that self.dbg.GetSelectedPlatform().GetTriple() is not a good way
to get the triple of the process, as it returns the incorrect triple in case of a
32-bit process running on a 64-bit platform.
Instead, go the long way round and ask the stub for the process triple. This
fixes the test for i386.
llvm-svn: 280922
Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.
This decreases the attach time to an android application by about 40%.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: https://reviews.llvm.org/D24236
llvm-svn: 280919
*** 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
As Pavel pointed out in a comment on llvm.org/pr30271, the VPATH I was
using here to eliminate duplication of a .cpp file had a side effect of
attempting to pull in a .o/.obj file from that same parent dir, where
other tests can be running in parallel. This is no good.
For now, I have removed the VPATH, which should address
llvm.org/pr30271. I have also removed the XFAIL.
llvm-svn: 280675
This code represents the Week of Code work I did on bringing up
lldb-server LLGS support for Darwin. It does not include the
Xcode project changes needed, as we don't want to throw that switch
until more support is implemented (i.e. this change is inert, no
build systems use it yet. I've verified on Ubuntu 16.04, macOS
Xcode and macOS cmake builds).
This change does some minimal refactoring of code that is shared
with the Linux LLGS portion, moving it from NativeProcessLinux into
NativeProcessProtocol. That code is also used by NativeProcessDarwin.
Current state on Darwin:
* Process launching is implemented. (Attach is not).
Launching on devices has not yet been tested (FBS/BKS might
need a bit of work).
* Inferior waitpid monitoring and communication of exit status
via MainLoop callback is implemented.
* Memory read/write, breakpoints, thread register context, etc.
are not yet implemented. This impacts process stop/resume, as
the initial launch suspended immediately starts the process
up and running because it doesn't know it is supposed to remain
stopped.
* I implemented the equivalent of MachThreadList as
NativeThreadListDarwin, in anticipation that we might want to
factor out common parts into NativeThreadList{Protocol} and share
some code here. After writing it, though, the fallout from merging
Mach Task/Process into a single concept plus some other minor
changes makes the whole NativeThreadListDarwin concept nothing more
than dead weight. I am likely going to get rid of this class and
just manage it directly in NativeProcessDarwin, much like I did
for NativeProcessLinux.
* There is a stub-out call for starting a STDIO thread. That will
go away and adopt the MainLoop pselect-based IOObject reading.
I am developing the fully-integrated changes in the following repo,
which contains the necessary Xcode bits and the glue that enables
lldb-debugserver on a macOS system:
https://github.com/tfiala/lldb/tree/llgs-darwin
This change also breaks out a few of the lldb-server tests into
their own directory, and adds some $qHostInfo tests (not sure why
I didn't write those tests back when I initially implemented that
on the Linux side).
llvm-svn: 280604
Part of TestGDBRemoteMemoryRead has been disabled since r259379 because it was incompatible with
python3. This changes the test to use the lldb-server test framework, which is a more appropriate
method of testing raw stub behaviour anyway (and should avoid the whole python 3 issue).
llvm-svn: 279039
"Incorrect" file name seen on Android whene the main executable is
called "app_process32" (or 64) but the linker specifies the package
name (e.g. com.android.calculator2). Additionally it can be present
in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc
file system based on the base address sepcified by the linker in case
we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
Summary:
This is a slightly reworked version of D16322, which I had reverted because it did not do what it
advertised. Differences from the previous version are:
- moved the code for cleaning up the remote working dir to a later point as it was removing the
log file before we could get to it.
- specialised log downloading code for gdb-remote tests is not needed, as this will cover that
use case as well.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21898
llvm-svn: 274491
Summary:
"gcc" is equivalent to "ehframe" in ProcessGDBRemote, but
only "ehframe" was a valid response in the test suite.
Reviewers: tfiala, jasonmolenda, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18807
llvm-svn: 267459
Summary:
On some android targets, a binary can produce additional garbage (e.g. warning messages from the
dynamic linker) on the standard error, which confuses some tests. This relaxes the stderr
expectations for targets known for their chattyness.
Reviewers: tfiala, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D19114
llvm-svn: 266326
A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.
These two test cases:
tools/lldb-server/lldbgdbserverutils.py
python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.
These test cases:
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
python_api/sbdata/TestSBData.py (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly. For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.
These test case:
python_api/sbdata/TestSBData.py (second change)
functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.
Differential Revision: http://reviews.llvm.org/D18985
llvm-svn: 266315
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
Previously we had 3 different method to run shell commands on the
target and 4 copy of code waiting until a given file appears on the
target device (used for syncronization). This CL merges these methods
to 1 run_platform_command and 1 wait_for_file_on_target functions
located in some utility classes.
Differential revision: http://reviews.llvm.org/D18789
llvm-svn: 265398
Summary:
Debug info is used only by the client and lldb-server tests do not even have the client component
running, as they communicate with the server directly. Therefore, running the tests for each
debug info type is unnecessarry.
This adds general ability to mark a test class as not dependent on debug info, and marks all
lldb-server tests as such.
Reviewers: tberghammer, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18598
llvm-svn: 265017
Summary:
Some tests (Hc_then_Csignal_signals_correct_thread, at least) were sending a "continue" packet in
one expect_gdbremote_sequence invocation, and "expecting" the stop-reply in another call. This
posed a problem, because the were packets were not persisted between the two invocations, and if
the stub was exceptionally fast to respond, the packet would be received in the first invocation
(where it would be ignored) and then the second invocation would fail because it could not find
the packet.
Since doing matching in two invocations seems like a reasonable use of the packet pump, instead
of fixing the test, I make sure the packet_pump supports this usage by making the list of
captured packets persistent.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18140
llvm-svn: 263629
Summary:
Normally, when the remote stub is not ready, we will get ECONNREFUSED during the connect()
attempt. However, due to the way how ADB forwarding works, on android targets the connect() will
always be successful, but the connection will be immediately dropped if ADB could not connect on
the remote side. This commit tries to detect this situation, and report it as "connection
refused" so that the upper test layers attempt the connection again.
Reviewers: tfiala, tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D18146
llvm-svn: 263439
The problem with the original patch (and my first attempt to fix) was that the value debug
monitor flags could persist from one test to another. Resetting the value in the setUp() function
fixes the problem.
llvm-svn: 262713
Summary:
this enables download of remote log files for llgs and debugserver tests (previously we were just
passing the host file name which obviously did not work). Note this also changes the debugserver
logging to work only when logging has been requested on the command line, whereas previously it
would log unconditionally. I can change it back if anyone is relying on this, but I thought I'd
make this consistent.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17798
llvm-svn: 262597
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
Summary:
gdb-remote tests are not able to use the same logging mechanisms as the rest of our tests, and
currently we get no host logs from them, even though the tests themselves have logging
capability. This commit changes that. When user specifies that he would like to log the
gdb-remote channel (--channel gdb-remote argument to dotest.py), we write detailed logs to the
<TEST_ID>-host.log file, just like we would in the case of regular tests. If this argument is not
specified, we only log the serious messages to stderr, which matches the existing behaviour.
Reviewers: tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16858
llvm-svn: 259774
This patch attempts to solve the Python 2 / Python 3 incompatibilities by
introducing a new `encoded_file` abstraction that we use instead of
`io.open()`. The problem with the builtin implementation of `io.open` is
that `read` and `write` accept and return `unicode` objects, which are not
always convenient to work with in Python 2. We solve this by making
`encoded_file.open()` return the same object returned by `io.open()` but
with hooked `read()` and `write()` methods. These hooked methods will
accept binary or text data, and conditionally convert what it gets to a
`unicode` object using the correct encoding. When calling `read()` it
also does any conversion necessary to convert the output back into the
native `string` type of the running python version.
Differential Revision: http://reviews.llvm.org/D16736
llvm-svn: 259379
This patch marks some known failures and puts on expectedFailureLinux decorator to have testsuite xfail them.
Affected tests are:
test/functionalities/watchpoint/step_over_watchpoint.py
test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
test/tools/lldb-server/TestGdbRemoteSingleStep.py
test/tools/lldb-server/TestGdbRemote_vCont.py
llvm-svn: 258315
Summary:
On linux we need the process to give us special permissions before we can attach to it.
Previously, the code for this was copied into every file that needed it. This moves the code to a
central place to reduce code duplication.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15992
llvm-svn: 257319
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
`sets.Set` has been deprecated in favor of `set` since 2.6, and
`string.maketrans` has to be special cased. In Python 3 there
is `str.maketrans`, `bytes.maketrans`, and `bytearray.maketrans`
and you have to choose the correct one. So we need to introduce
a runtime version check at this site.
llvm-svn: 252348
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
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
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
Jason Molenda