Summary:
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters.
This fixes https://llvm.org/bugs/show_bug.cgi?id=28709
Patch from malaperle@gmail.com
Reviewers: clayborg, ki.stfu
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D22902
llvm-svn: 277117
This change breaks up the monolithic TestConcurrentEvents.py into a
separate subdir per test method. This allows them to run concurrently,
reduces the chance of a timeout occurring during normal operation, and
allows us to home in on any test methods that may be locking up.
This is step one in the process of squashing timeouts in these test
methods.
The reason for breaking each test method into its own file is to make it
very clear to us if there are a subset of the tests that do in fact lock
up frequently. This will limit how much hunting we need to do to
recreate it.
The reason for putting each file in a separate subdirectory is so that
our concurrent test runner can run multiple test files at the same time.
The unit of serialization in the LLDB test suite is the test directory,
so moving them into separate directories enables the test runner to do
more at the same time.
This change introduces usage of VPATH from gnu make. I use that to
facilitate keeping a single copy of the main.cpp in the parent
concurrent_events directory. Initially I had tried specifying the source
file as ../main.cpp, but our current makefile rules get confused by that
and then also build the output into the parent directory, which defeats
the ability to run each of the test methods concurrently. In the event
that not all systems support VPATH, I can do a bit of surgery on the
Makefile rules and attempt to make it smarter with regards to relative
paths to source files used in the build.
llvm-svn: 276478
"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
This reverts r275782.
The problem with the commit is that it reports an additional "exit (1)" error for every file
containing a failing test, which is far more than I had intended to do. I'll need to come up with
a more fine-grained way of achieving the result.
llvm-svn: 275791
Summary:
We've run into this problem when the test errored out so early (because it could not connect to
the remote device), that the code in D20193 did not catch the error. This resulted in the test
suite reporting success with 0 tests being run.
This patch makes sure that any non-zero exit code from the inferior process gets reported as an
error. Basically I expand the concept of "exceptional exits", which was previously being used for
signals to cover these cases as well.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22404
llvm-svn: 275782
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
Changes to the underlying logging infrastructure in Fall 2016 Darwin
OSes were no longer showing up NSLog messages in command-line LLDB.
This change restores that functionality, and adds test cases to
verify the new behavior.
rdar://26732492
llvm-svn: 275472
Android API <= 16 header do not have these symbols defined, but the kernel does support the
relevant calls. And in general, since these calls are on a best-effort basis, it won't hurt even
if we try to run in on a really ancient kernel.
llvm-svn: 275393
* Previously -break-enable mistakenly set BP's enabled flag to false.
* These commands print fake =breakpoint-modified messages, what's not
needed anymore because that events are come in normal way.
* Add tests for -break-enable/-break-disable commands
Initial patch from xuefangliang@hotmail.com. The test case was improved by me.
Differential Revision: http://reviews.llvm.org/D21757
llvm-svn: 275381
Summary:
LLDBTestResult.hardMarkAsSkipped marked the whole class as skipped when the first class in the
test failed the category check. This meant that subsequent tests in the same class did not run
even if they were passing the category filter. Fix that.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22213
llvm-svn: 275173
We had some clients that had added old source paths remappings to their .lldbinit files and they were causing trouble at a later date. This fix should help mitigate these issues.
<rdar://problem/26358860>
llvm-svn: 274948
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo ®ion_info).
Reviewers: clayborg
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D21751
llvm-svn: 274741
Summary:
One of the tests there does not work with gcc, so I'm spinning that off into a separate test, so
that we can XFAIL it with more granularity.
I am also renaming the test to reflect the fact that it no longer tests only integer arguments.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21923
llvm-svn: 274505
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
@unittest2.expectedFailure("rdar://7796742")
Which was covering up the fact this was failing on linux and hexagon. I added back a decorator so we don't break any build bots.
llvm-svn: 274388
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
Summary:
As this test will create a new target, it will cause all following tests
to fail when running in platform mode, if the new target does not match
the existing architecture (for example, x86 vs x86_64).
Reviewers: zturner, spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21906
llvm-svn: 274364
I overlooked the possibility of certain targets translating increment statement into a read and write.
In this case we replace increment statement with an assignment.
llvm-svn: 274215
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types.
Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix.
Also added a test case to ensure this doesn't regress in the future.
llvm-svn: 273750
This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses.
This patch also adds tests to verify this functionality.
Differential revision: http://reviews.llvm.org/D21280
llvm-svn: 272916
Prior to this we would display the typename for "TestObj<-1>" as "TestObj<4294967295>" when we showed the type. Expression parsing could also fail because we would fail to find the mangled name when evaluating expressions.
The issue was we were losing the signed'ness of the template integer parameter in DWARFASTParserClang.cpp.
<rdar://problem/25577041>
llvm-svn: 272434
This enables a couple of tests which have been shown to run reliably on the
linux x86 buildbot. If you see a failure after this commit, feel free to add
the xfail back, but please make it as specific as possible (i.e., try to make
it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9).
llvm-svn: 272326
If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.
This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found. Finally, it adds a test case.
<rdar://problem/25094302>
llvm-svn: 271551
For Thread Sanitizer reports, LLDB tries to find a global variable declaration
corresponding to the racy address in order to provide a filename and line
number. This commit changes the lookup of the variable to use the mangled
name for lookup and fall back to the demangled version if unavailable. This
is needed to report locations of races on Swift global variables.
I've also added a test to make sure we look up C++ globals correctly.
rdar://problem/26459401
Differential Revision: http://reviews.llvm.org/D20760
llvm-svn: 271433
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
Summary:
using stdio in tests does not work on windows, and it is not completely reliable on linux.
Avoid using stdio in this test, as it is not necessary for this purpose.
Reviewers: clayborg
Subscribers: lldb-commits, zturner
Differential Revision: http://reviews.llvm.org/D20567
llvm-svn: 270831
T x;
U y;
doing
x = *((T*)y)
is undefined behavior, even if sizeof(T) == sizeof(U), due to pointer aliasing rules
Fix up a couple of places in LLDB that were doing this, and transform them into a defined and safe memcpy() operation
Also, add a test case to ensure we didn't regress by doing this w.r.t. tagged pointer NSDate instances
llvm-svn: 270793
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr.
llvm-svn: 270780
TestCallUserAnonTypedef.py and TestIRInterpreter.py fail to limitation of JIT expressions in handling hard float ABI targets.
TestBSDArchives.py fails due to python unicode error.
TestBuiltinTrap.py fails due to wrong line information generated by some gcc versions.
llvm-svn: 270745
m_decl_objects is problematic because it assumes that each VarDecl has a unique
variable associated with it. This is not the case in inline contexts.
Also the information in this map can be reconstructed very easily without
maintaining the map. The rest of the testsuite passes with this cange, and I've
added a testcase covering the inline contexts affected by this.
<rdar://problem/26278502>
llvm-svn: 270474
There is flakiness somewhere in the core infrastructure on Windows,
so to get the buildbot reliably green we need to mark all tests
as flaky.
llvm-svn: 270460
The error was not getting propagated to the caller, so the higher layers thought the breakpoint
was successfully set & resolved.
I added a testcase, but it assumes 0x0 is not a valid place to set a breakpoint. On most systems
that is true, but if it isn't true of your system, either find another good place and add it to the
test, or x-fail the test.
<rdar://problem/26345962>
llvm-svn: 270014
TestTopLevelExprs fails on arm and aarch64 linux similar to behaviour on android.
A bug exists here: llvm.org/pr27787.
This patch marks xfail on arm and aarch64.
llvm-svn: 269980
TestWatchLocation.py fails on arm-linux target due to unicode error in lldb testsuite.
This is a known issue and same test fails on OS X with similar reason.
I have reported a bug and marked this test as xfail for arm-linux targets.
llvm-svn: 269860
Both of above tests fail on arm and bugs have been reported on android already.
Adding arm-linux decorator because android decorator doesnt xfail these test when run on linux.
llvm-svn: 269647
The variables referenced in the print message are not defined. Simply state
that the requisite script is not found. Correct grammar to indicate that the
tests are rather likely to fail rather than unlikely to fail.
llvm-svn: 269628
The parameter here is a list, not a string. Ensure that the we splat the list
into arguments prior to invoke os.path.join. This would previously fail with a
`startswith` is not a member of `list`.
llvm-svn: 269627
Summary:
print build errors nicely in test output
This test infrastructure change adds a new Python exception
for test subject builds that fail. The output of the build
command is captured and propagated to both the textual test
output display code and to the test event system.
The ResultsFormatter objects have been modified to do something
more useful with this information. The xUnit formatter
now replaces the non-informative Python build error stacktrace
with the build error content. The curses ResultsFormatter
prints a 'B' for build errors rather than 'E'.
The xUnit output, in particular, makes it much easier for
developers to track down test subject build errors that cause
test failures when reports come in from CI.
Reviewers: granata.enrico
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20252
llvm-svn: 269525
Summary:
This change enhances the LLDB test infrastructure to convert
load-time exceptions in a given Python test module into errors.
Before this change, specifying a non-existent test decorator,
or otherwise having some load-time error in a python test module,
would not get flagged as an error.
With this change, typos and other load-time errors in a python
test file get converted to errors and reported by the
test runner.
This change also includes test infrastructure tests that include
covering the new work here. I'm going to wait until we have
these infrastructure tests runnable on the main platforms before
I try to work that into all the normal testing workflows.
The test infrastructure tests can be run by using the standard python module testing practice of doing the following:
cd packages/Python/lldbsuite/test_event
python -m unittest discover -s test/src -p 'Test*.py'
Those tests run the dotest inferior with a known broken test and verify that the errors are caught. These tests did not pass until I modified dotest.py to capture them properly.
@zturner, if you have the chance, if you could try those steps above (the python -m unittest ... line) on Windows, that would be great if we can address any python2/3/Windows bits there. I don't think there's anything fancy, but I didn't want to hook it into test flow until I know it works there.
I'll be slowly adding more tests that cover some of the other breakage I've occasionally seen that didn't get collected as part of the summarization. This is the biggest one I'm aware of.
Reviewers: zturner, labath
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D20193
llvm-svn: 269489
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
The adding of <atomic> to test_common.h broke 12 tests on Darwin. We work around this by not including <atomic> when building on darwin for libstdc++ tests.
llvm-svn: 269372
This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms).
Patch by cameron314
Differential Revision: http://reviews.llvm.org/D19124
llvm-svn: 269340
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
Summary:
test_listener_event_process_state checks for Threads
and Frames in the multithreaded_queue. The listener_func has
more computational load, which may be latter executed than the
pop leading to the failure. This patch tries to only check for
frames in listener_func as presence of frames also confirms
prescence of threads and avoids the second push into the
multithreaded_queue.
Reviewers: lldb-commits, clayborg, labath
Differential Revision: http://reviews.llvm.org/D20091
llvm-svn: 269168
Test uses x1 in breakpoint expression while objdump shows that x1 is never used in the code and may have random values.
Using x0 make sure that we are using a registe that will have a positive value and breakpoint expression will evaluate true atleast once.
llvm-svn: 269164
Summary:
TestExitDuringStep was very rarely hanging on the buildbots. I can't be sure, but I believe this
was because of the fact that it declared its pseudo_barrier variable as "volatile int", which is
not sufficient to guarantee corectness (also, all other tests used atomic variables for this, and
they were passing reliably AFAIK). Besides switching to an atomic variable in this test as well,
I have also took this opportunity to unify all the copies of the pseudo_barrier code to a single
place to reduce the chance of this happening again.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20065
llvm-svn: 269025
This tests both that we set the breakpoint on the right line, and that restricting by file
and/or the function, we get the right breakpoints.
llvm-svn: 269004
This change addresses a hang/segfault in TestEvents.py. The threads that
run the listener loops now do an SBListener.Clear() before they wrap up
their work. This prevents the test from trying to clean up the
SBListener too late.
There is a separate issue here which is that we should prevent this
clean-up time lock-up, but that is out of scope for this particular
change. I'd like to get these tests back and running the normal flow
rather than skipping them.
This addresses:
llvm.org/pr25924 (at least, the OS X side, although I suspect this will
also address Linux)
http://reviews.llvm.org/D19983
reviewed by: Jim Ingham
llvm-svn: 268653
Summary:
We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this
function does not understand the die encoding used by the DWO files. Instead use GetDIE on the
SymbolFileDWARF, which is overriden in DWO to do the right thing.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits, ovyalov
Differential Revision: http://reviews.llvm.org/D19927
llvm-svn: 268615
1. Fixed semicolon placement in the lambda in the test itself.
2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.)
3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording.
4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows.
Differential Revision: http://reviews.llvm.org/D19606
llvm-svn: 268573
Summary:
As these are really testing separate issues, they should be run as separate
tests.
Reviewers: zturner, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19690
llvm-svn: 268397
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration
in 'foo' member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 268083
This reverts commit r267833 as it breaks the build. It looks like some work in progress got
committed together with the actual fix, but I'm not sure which one is which, so I'll revert the
whole patch and let author resumbit it after fixing the build error.
llvm-svn: 267861
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo'
member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 267833
There's an open bug with calling functions in the inferior. And Windows doesn't have the POSIX function getpid().
Differential Revision: http://reviews.llvm.org/D19626
llvm-svn: 267800
Use __attribute__((regparm(x))) to ensure the compiler enregisters at least some arguments when calling functions.
Differential Revision: http://reviews.llvm.org/D19548
llvm-svn: 267616
Python 3.5 is pickier about the distinction between chars and bytes (and strings and bytearrays) than Python 2.7.
Differential Revision: http://reviews.llvm.org/D19510
llvm-svn: 267562
Summary:
lldb-server tests are currently being skipped on the
check-lldb target. This is because we get the path of
lldb-server by modifying the path to the lldb executable.
However, by this point, we've changed directories, and a
relative path to the build/bin directory will no longer point
to the location of lldb-server.
Storing an absolute path solves this issue.
Reviewers: vharron, zturner, tfiala, labath
Subscribers: labath, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19082
llvm-svn: 267463
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
Test added in r267248 exposed a bug in handling of dwarf produced by clang>=3.9, which causes a
crash during expression evaluation. Skip the test until this is sorted out.
llvm-svn: 267407
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements
This has a couple subtle points but is mostly as straightforward as it sounds
Add a parray N <expr> alias for this new mode
Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this
llvm-svn: 267372
Some older versions of clang emitted bit offsets that were negative and these bitfields would have their bitfield-ness stripped off and it would cause a clang assertion in clang assertions were enabled. I updated the bitfield C test to make sure we don't regress.
<rdar://problem/21082998>
llvm-svn: 267248
This change moves all the test event handling and its related
ResultsFormatter classes out of the packages/Python/lldbsuite/test dir
into a packages/Python/lldbsuite/test_event package. Formatters are
moved into a sub-package under that.
I am limiting the scope of this change to just the motion and a few
minor issues caught by a static Python checker (e.g. removing unused
import statements).
This is a pre-step for adding package-level tests to the test event
system. I also intend to simplify test event results formatter selection
after I make sure this doesn't break anybody.
See:
http://reviews.llvm.org/D19288
Reviewed by:
Pavel Labath
llvm-svn: 266885
Also does the following:
* adopts PEP8 naming convention for OptionalWith class (now
optional_with).
* moves test_runner/lldb_utils.py to lldbsuite/support/optional_with.py.
* packages tests in a subpackage of test_runner per recommendations in
http://the-hitchhikers-guide-to-packaging.readthedocs.org/en/latest/creation.html
Tests can be run from within pacakges/Python/lldbsuite/test via this
command:
python -m unittest discover test_runner
The primary cleanup this allows is avoiding the need to muck with the
PYTHONPATH variable from within the source files. This also aids some
of the static code checkers as they don't need to run code to determine
the proper python path.
llvm-svn: 266710
This ensure lldbinline.test_file paths are tracked as .py
files rather than .pyc files.
Also, this change adds an assert to the test infrastructure
if a filename that is not ending in .py is attempted to be
added to the test events infrastructure where we track test
results.
See:
http://reviews.llvm.org/D19215
Earlier revision reviewed by:
Pavel Labath
llvm-svn: 266664
The race boiled down to this:
If a test worker queue is able to run the test inferior and
clean up before the dosep.py listener socket is spun up, and
the worker queue is the last one (as would be the case when
there's only one test rerunning in the rerun queue), then
the test suite will exit the main loop before having a chance
to process any test events coming from the test inferior or
the worker queue job control.
I found this race to be far more likely on fast hardware.
Our Linux CI is one such example. While it will show
up primarily during meta test events generated by
a worker thread when a test inferior times out or
exits with an exceptional exit (e.g. seg fault), it only
requires that the OS takes longer to hook up the
listener socket than it takes for the final test inferior
and worker thread to shut down.
See:
http://reviews.llvm.org/D19214
reviewed by:
Pavel Labath
llvm-svn: 266624
Summary:
The original breakpoint location test was failing for linux, because the compilers here tend to
merge the full-object and subobject destructors even at -O0 (as a result, we are getting only 2
breakpoint locations, and not 4 as the test expected. The fixup in r266164 substantially weakened
the test, as it now did not check whether both kinds of destructors were being found.
Because of these contraints, I have altered the logic of the test. It sets the
breakpoint by name, and then independently verifies that the breakpoint is set on the correct
demangled symbol name (which is not very meaningful since both kinds of destructors demangle to
the same name) *and* the correct symbol address (which is obtained by looking up the mangled
symbol name).
Reviewers: clayborg
Subscribers: ovyalov, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D19052
llvm-svn: 266416
Ilia K