Summary:
Before:
AssertionError: False is not True : Process is launched successfully
After:
AssertionError: False is not True : Command 'run a.out' failed.
>>> error: invalid target, create a target using the 'target create' command
>>> Process could not be launched successfully
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, vharron
Differential Revision: http://reviews.llvm.org/D9948
llvm-svn: 238363
Summary:
Since we don't yet have remote windows debugging, it should be safe to assume
that the remote target uses unix path separators.
Reviewers: ovyalov, zturner, clayborg, vharron
Reviewed By: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9633
llvm-svn: 237006
the test has passed in the last 300 runs, enabling to see what the build bot says. Also,
downgrading skipIfGcc to XFAIL, with plans of enabling it in the future if it shows to be
working.
llvm-svn: 236496
Some have been marked as skipIfLinux for years.
The seem to be passing so I've enabled them.
Differential Revision: http://reviews.llvm.org/D9428
llvm-svn: 236403
There was a lot of code that was checking "if self.getPlatform() == 'darwin'" which is not correct. I fixed this by adding a:
lldbtest.platformIsDarwin()
which returns true if the current platform's OS is "macosx", "ios" or "darwin". These three valid darwin are now returned by a static function:
lldbtest.getDarwinOSTriples()
Fixed up all places that has 'if self.getPlatform() == "darwin":' with "if self.platformIsDarwin()" and all instances of 'if self.getPlatform() != "darwin":' with "if not self.platformIsDarwin()". I also fixed some darwin decorator functions to do the right thing as well.
llvm-svn: 233933
Removed expectedFailureLinux from failures that I was unable to
reproduce, updated and improved some other comments near XFAIL tests
Differential Revision: http://reviews.llvm.org/D8676
llvm-svn: 233716
Adds @skipIfPlatform and @skipUnlessPlatform decorators which will skip if /
unless the target platform is in the provided platform list.
Test Plan:
ninja check-lldb shows no regressions.
When running cross platform, tests which cannot run on the target platform are
skipped.
Differential Revision: http://reviews.llvm.org/D8665
llvm-svn: 233547
To run tests against a different target platform many extra compiler flags are
needed to specify sysroot, include dirs, etc. The environment variable
CFLAGS_EXTRAS seems suited for this purpose except that several Makefiles
clobber the current flags. This change modifies all of these to add to
CFLAGS_EXTRAS instead.
Test Plan:
Verify no regressions in ninja check-lldb.
Run tests using CFLAGS_EXTRAS to specify cross compilation flags for a different
target running lldb-server platform.
Differential Revision: http://reviews.llvm.org/D8559
llvm-svn: 233066
This fixes tests on clang-3.4
AFAICT, these flags have the same affect and -fstandalone-debug wasn't
added until after clang-3.4
Committed to try to fix buildbot
Differential Revision: http://reviews.llvm.org/D8347
llvm-svn: 232326
The issue was the previous code tried to stop on the following code in main.c:
21 // Stop here and set values
22 printf ("Val - %d Mine - %d, %d, %llu. Ptr - %d, %d, %llu\n",
23 val,
24 mine.first_val, mine.second_val, mine.third_val,
25 ptr->first_val, ptr->second_val, ptr->third_val);
We we set a source regex breakpoint on "// Stop here and set values" we would set a breakpoint on line 22 as expected.
The problem is the most recent clang compiler generates a line table like this
0x1000: main.c:23 // Loading of "val" into a register
0x1010: main.c:24 // Load mine.first_val, mine.second_val, mine.third_val values into registers or on the stack
0x1020: main.c:25 // Load ptr->first_val, ptr->second_val, ptr->third_val values into registers or on the stack
0x1030: main.c:22 // Call to printf
In this test, we run to line 22, then we use python to modify the value of "val" and then continue to another breakpoint and try to read the STDOUT from the printf to verify the values changed correctly.
With the above line table the value for "val" had already been loaded into a register so the string from printf would be incorrect.
Doing an easy fix for now by changing the code to:
21 // Stop here and set values
22 printf ("Val - %d Mine - %d, %d, %llu. Ptr - %d, %d, %llu\n", val,
23 mine.first_val, mine.second_val, mine.third_val,
24 ptr->first_val, ptr->second_val, ptr->third_val);
Now we get a line table entry for line 22 that is before any locals are read from the stack into registers.
I need to follow up with the compiler guys and see if we can get a fix for this as anyone setting file + line breeakpoints might be very surprised to have code from lines below the current line already have had their code run.
llvm-svn: 232068
Summary:
There was a race condition regarding the output of the inferior process. The reading of the
output is performed on a separate thread, and there was no guarantee that the output will get
eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not
returning anything even though the process was terminated and would definitely not produce any
further output. This was usually happening only under very heavy system load, but it can be
reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived).
This patch addresses this by adding synchronization capabilities to the Communication thread.
After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has
been processed by the read thread. This function is then called after every public event which
stops the process to obtain the entire process output.
Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8246
llvm-svn: 232023
Summary: This patch adds a few comments for GetValueDidChange and contains improvements for TestValueVarUpdate.py test which checks ValueObject::GetValueDidChange for complex types.
Reviewers: zturner, granata.enrico, clayborg
Reviewed By: clayborg
Subscribers: jingham, lldb-commits, granata.enrico, zturner, clayborg
Differential Revision: http://reviews.llvm.org/D8103
llvm-svn: 231526
Summary:
Using std::thread/random instead of pthread/rand.
Two of them also suffered from the synchronization problem in D7916.
Reviewers: clayborg, zturner, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7991
llvm-svn: 230993
clang-3.5+ outputs FullDebugInfo by default for Darwin/FreeBSD targets.
Other targets do not, which causes several tests to fail. This flag
enables FullDebugInfo for all targets.
Fixes the following tests:
TestCallStdStringFunction.py
TestDataFormatterSkipSummary.py
TestDataFormatterStdIterator.py
TestDataFormatterStdList.py
TestDataFormatterStdString.py
TestSBValuePersist.py
TestStringPrinter.py
TestTypeCompletion.py
llvm-svn: 230831
Fixed test case to copy redirected stdout/stderr files from remote
target to host
llgs wasn't bothering to put the pty master file handle in the right
place if stdout/stderr were redirected to a file. It is still needed
for stdin.
Corrected some log message text
llvm-svn: 229141
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
This was causing problems on clang 602 branches that use MemoryObjects to as the container for opcode bytes instead of a plain array of bytes. So we were asking for 3 bytes to be disassembled at address 0xffffffffffffffff which would cause an unsigned overflow and cause the MemoryObject to refuse to read anymore bytes.
llvm-svn: 227153
These fix various issues with path handling and disable a few tests
which use features of LLVM which are not yet supported on Windows.
llvm-svn: 226042
Summary:
If we do not mark them as skip, they are still executed, which in
turn is leading to an assertion failure. The change also adds
skipIfLinux to a testlet which was not previously marked with
skipIfLinux. This is because running even that test let leads to an
assertion failure.
Test Plan: dotest.py -C clang -p TestEvents.py
Reviewers: vharron
Reviewed By: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6715
llvm-svn: 224644
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
The following lldb unit tests fail check-lldb on ubuntu:
TestDataFormatterStdMap.py
TestDataFormatterStdVBool.py
TestDataFormatterStdVector.py
TestDataFormatterSynthVal.py
TestEvents.py
TestInitializerList.py
TestMemoryHistory.py
TestReportData.py
TestValueVarUpdate.py
These unit test failures are for non-core functionality. The intent is to
reduce the check-lldb FAILS to core functionality FAILS and then circle
back later and fix these FAILS at a later date.
llvm-svn: 222608
This test has intermittently failed on FreeBSD for quite some time when
run as part of the full test suite. It generally passes when run by
itself. Mark as expected failure for now to reduce buildbot noise.
llvm.org/pr15039 test fails intermittently on FreeBSD
llvm-svn: 222134
The problem was that SBTarget::ReadMemory() was making a new section offset lldb_private::Address by doing:
size_t
SBTarget::ReadMemory (const SBAddress addr,
void *buf,
size_t size,
lldb::SBError &error)
{
...
lldb_private::Address addr_priv(addr.GetFileAddress(), NULL);
bytes_read = target_sp->ReadMemory(addr_priv, false, buf, size, err_priv);
This is wrong. If you get the file addresss from the "addr" argument and try to read memory using that, it will think the file address is a load address and it will try to resolve it accordingly. This will work fine if your executable is loaded at the same address (no slide), but it won't work if there is a slide.
The fix is to just pass along the "addr.ref()" instead of making a new addr_priv as this will pass along the lldb_private::Address that is inside the SBAddress (which is what we want), and not always change it into something that becomes a load address (if we are running), or abmigious file address (think address zero when you have 150 shared libraries that have sections that start at zero, which one would you pick). The main reason for passing a section offset address to SBTarget::ReadMemory() is so you _can_ read from the actual section + offset that is specified in the SBAddress.
llvm-svn: 221213
Siva Chandra