This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues
Comes with a test case
llvm-svn: 280172
Reports an error instead. We can fix this later to make persistent variables
work, but right now we hit an LLVM assertion if we get this wrong.
<rdar://problem/27770298>
llvm-svn: 279850
Clang on ARM64 was making the three Function methods with identical bodies have
one implementation that was shared. That threw off the count of breakpoints, since
we don't count as separate locations three functions with the same address.
I also cleaned up the test case while I was at it.
<rdar://problem/27001915>
llvm-svn: 279800
The newer event-based tests I added neglected to do the
macOS 10.12 check in the setup. This caused earlier macOS
test suite runs to attempt to compile code that doesn't exist.
llvm-svn: 279672
The test was attempting to backtrace a process after every state change event (including the
"running", and "restarted" ones), which is not a good idea.
llvm-svn: 279512
This test was using a condition that would compare a variable against the register that would hold
it. It was failing with clang on arm64 because clang put the variable on the stack.
This is not a supportable way to write tests.
llvm-svn: 279345
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
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
Summary:
referencing a user-defined operator new was triggering an assert in clang because we were
registering the function name as string "operator new", instead of using the special operator
enum, which clang has for this purpose. Method operators already had code to handle this, and now
I extend this to cover free standing operator functions as well. Test included.
Reviewers: spyffe
Subscribers: sivachandra, paulherman, lldb-commits
Differential Revision: http://reviews.llvm.org/D17856
llvm-svn: 278670
debuggerd is a crash reporting system on android what installs some
signal handler for SEGV to print a backtrace in the log. Its behavior
breaks tests where the test tries to continue after a SEGV so we skip
them as this behavior isn't required on android anyway.
llvm-svn: 278510
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
This was a shadowed variable error from the big Expression Parser plugin-ification. I also
added a test case for this.
<rdar://problem/27682376>
llvm-svn: 277662
This commit is causing problems on gcc-* compiler with version number sufix.
Requires a new solution will post a follow up patch.
Differential revision: https://reviews.llvm.org/D20386
llvm-svn: 277453
Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.
The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout.
I have reused them and parse i386 files manually, and fill them in the
same struct.
Also added some error handling during parsing that checks if the
available bytes in the buffer are enough to fill the structures.
The i386 core file test case now passes.
For reference on the structures layout, I generally used the
source of binutils (bfd, readelf)
Bug: https://llvm.org/bugs/show_bug.cgi?id=26947
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22917
llvm-svn: 277140
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
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
The android dirty stderr problem has uncovered an issue where lldbutil.expect_state_changes was
reading events other than state change events, which resulted in general confusion. Make it more
strict to accept *only* state changes.
llvm-svn: 266327
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 fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.
- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
an explicit *signed* char type for encoding eEncodingSint and bit size 8,
instead of the default platform char type (which may be unsigned).
This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
unit test case.
- The test/expression_command/char/TestExprsChar.py test case is known to
fail on platforms defaulting to unsigned char (pr23069), and just needs
to be xfailed on s390x like on arm.
- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
case defines a vector of "char" and implicitly assumes to be signed.
Use an explicit "signed char" instead.
Differential Revision: http://reviews.llvm.org/D18979
llvm-svn: 266309
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
result_formatter used inspect.getfile() to get the python file name, which returned "*.pyc" if
the bytecode file was present. This resulted in files being displayed with the wrong extension,
and more critically, would confuse the rerun logic because it would try to rerun the pyc file
(which resulted in an empty rerun list as unittest refused to run those).
Fix: use inspect.getsourcefile() instead.
I am not sure why does was not an issue before. I can only assume that some system update
tricked python into producing bytecode files more aggressively.
llvm-svn: 266192
When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.
Differential Revision: http://reviews.llvm.org/D19035
llvm-svn: 266145
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these. So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute). So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.
llvm-svn: 266093
this test was unintentionally XFAILed due to a change in the behavior of the expectedFailure
decorator. Fix that. Also, mark the test as debug-info independent while I'm in there.
llvm-svn: 266072
-thread-info in lldbmi does not conform to protocol. Should end with
current thread id as described here:
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Thread-Commands.html#GDB_002fMI-Thread-Commands
When printing all threads, the current thread id should be printed
afterwards.
Example:
-thread-info
^done,threads=[
{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",
args=[]},state="running"},
{id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
frame={level="0",addr="0x0804891f",func="foo",
args=[{name="i",value="10"}],
file="/tmp/a.c",fullname="/tmp/a.c",line="158"},
state="running"}],
current-thread-id="1"
(gdb)
Patch from jacdavis@microsoft.com
Reviewers: zturner, chuckr
Differential Revision: http://reviews.llvm.org/differential/revision/edit/18880/
llvm-svn: 265858
This test sets the compiler optimization level to -O1 and
makes some assumptions about how local frame vars will be
stored (i.e. in registers). These assumptions are not always
true.
I did a first-pass set of improvements that:
(1) no longer assumes that every one of the target locations has
every variable in a register. Sometimes the compiler
is even smarter and skips the register entirely.
(2) simply expects one of the 5 or so variables it checks
to be in a register.
This test probably passes on a whole lot more systems than it
used to now. This is certainly true on OS X.
llvm-svn: 265498
Summary:
The '-p' option for dotest.py was ignored in multiprocess mode,
as the -p argument to the inferior would overwrite the -p argument
passed on the command line.
Reviewers: zturner, tfiala
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18779
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265422
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:
There was a bug in linux core file handling, where if there was a running process with the same
process id as the id in the core file, the core file debugging would fail, as we would pull some
pieces of information (ProcessInfo structure) from the running process instead of the core file.
I fix this by routing the ProcessInfo requests through the Process class and overriding it in
ProcessElfCore to return correct data.
A (slightly convoluted) test is included.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18697
llvm-svn: 265391
Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping
This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch)
This makes those launch scenarios work transparently via shell expansion
Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly
Fixes rdar://problem/22749408
llvm-svn: 265357
This addresses the same problem as r264846 (the test not expecting the situation when two thread
hit the watchpoint simultaneously), but for a different test.
llvm-svn: 265294
Enrico has a bug on him to make this work across older libcxx list
and newer libcxx list simultaneously. Needed in preparation of
getting the OS X public CI to run the TSAN tests.
tracked by:
rdar://25499635
llvm-svn: 265188
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:
the inferior in the test deliberately does not lock a mutex when accessing the watched variable.
The reason for that is unclear as, based on the logs, the original intention of the test was to
check whether watchpoints get propagated to newly created threads, which should work fine even
with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time
to time) that two threads do manage the execute the "critical section" simultaneously, the test
will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2.
Given this, I have simply chose to lock the mutex always, so that we have more predictible
behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by
TestConcurrentEvents.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18558
llvm-svn: 264846
1 - If you plan on looking for the "(lldb) " prompt as a regular expression, look for "\(lldb\) " so you don't just find "lldb".
2 - Make sure to not use colors (specify --no-use-colors as an option to lldb when launching it) as our editline will print:
"(lldb) <color junk>(lldb) "
where "<color junk>" is a work around that is used to allow us to colorize our prompts. The bad thing is this will make pexepct code like this not execute as you would expect:
prompt = "\(lldb\) "
self.child.sendline("breakpoint set ...", prompt)
self.child.sendline("breakpoint clear ...", prompt)
The problem is the first "sendline" will create two lldb prompts and will match both the first and second prompts and you output will get off. So be sure to disable colors if you need to.
Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have spaces in your directory names. I modified custom_command.py to use shlex to parse arguments and I quoted the file path we sent down to the custom_command.write_file function.
llvm-svn: 264810
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers. Names defined by these are given priority over all other
symbol lookups.
This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way. It also adds a flag controlling
this to SBExpressionOptions so that this API is usable externally. It also adds
a test that validates that this works. (The test requires a fix to the Clang
AST importer which I will be committing shortly.)
<rdar://problem/22864976>
llvm-svn: 264662
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.
Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18228
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264351
It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do
llvm-svn: 264343
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.
Reviewed by Greg Clayton.
llvm-svn: 264162
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
the main reason is that our decorator contains extra fluff to "expect" crashes (which seem to
happen occasionaly on the android buildbot).
llvm-svn: 263633
Pavel Labath