Ninja apparently has issues with commands writing nul characters '\0' to stdout. When it
encounters a nul character, the rest of the output is skipped (I will file a bug with ninja about
that). This breaks the linux buildbot since it parses the ninja check-lldb output to get a list
of failures.
Recently, we have started outputting nul characters in lldb-server tests. This is probably
a bug in itself, but I am not addressing that now. This is just a workaround commit, which
prevents the nul characters from appearing in the output, and gets the buildbot operational again.
llvm-svn: 232805
Summary:
Presently, if a log file already exists, lldb simply starts overwriting bits of it, without
truncating or anything. This patch makes it use eFileOptionFileTruncate by default. It also adds
an --append option, which will append to the file without truncating. A test is included.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8450
llvm-svn: 232801
Summary:
This changes all reporting of addresses from lldb-mi to be 64 bit capable. There could have been cases where a 64 bit address was getting truncated to 32 bit format.
Patch from chuckr@microsoft.com
Reviewers: abidh, ChuckR
Reviewed By: abidh
Subscribers: paulmaybee, ki.stfu, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8238
llvm-svn: 232736
Summary:
GCC does not emit some DWARF required for the simplified formatter
to work. A workaround for it has been incorporated in the formatter.
The corresponding test TestDataFormatterStdMap has also been enabled
for GCC.
Test Plan: dotest.py -C <clang|gcc> -p TestDataFormatterStdMap
Reviewers: clayborg, vharron, granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8424
llvm-svn: 232678
Summary:
This test now passes for Clang and GCC. I do not know why it was
disabled for GCC with link to a bug which should not have had an
effect on this test.
Test Plan: dotest.py -C gcc -p TestDataFormatterStdIterator
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8396
llvm-svn: 232552
Summary:
The existing formatter in C++ has been removed as it was not being used.
The associated test TestDataFormatterStdVBool.py has been enabled for
both Clang and GCC on Linux.
Test Plan: dotest.py -p TestDataFormatterStdVBool
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8390
llvm-svn: 232548
Summary:
This test should have been enabled along with
7181dae1248cc1b03505cca1b7c6e3dfeffefc0a, but since the test was
actually crashing, I thought it was a much deeper problem. Turns out,
all I had to do was to add "-fno-limit-debug-info" when compiling
the test case.
The test is still skipped when the testcase is compiled with GCC.
Test Plan: dotest.py -p TestDataFormatterStdMap
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8364
llvm-svn: 232432
Summary:
After 7181dae1248cc1b03505cca1b7c6e3dfeffefc0a, this test progresses
much further but crashes. Will skip this test while I fix this properly.
Test Plan: dotest.py -p TestDataFormatterStdMap
Reviewers: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8361
llvm-svn: 232403
The test does the following:
1 - runs a program to main without the OS plug-in and verifies no OS threads are in the process
2 - loads the OS plug-in and verifies the 3 OS plug-in threads are now in the current process
3 - verify the register contents of each thread that shows up
4 - unload the python OS plug-in and verify that the OS threads are gone.
llvm-svn: 232401
Summary:
Also, change its return type to size_t to match the return types of
its callers.
With this change, std::vector and std::list data formatter tests
pass on Linux (when using libstdc++) with clang as well as with gcc.
These tests have also been enabled in this patch.
Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList>
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8337
llvm-svn: 232399
I think the issue that caused the random failure has been fixed. So I am enabling the tests again on Linux.
There are still some tests that are skipped on Linux due to different output. Those will be handled separately.
Tested with dotest.py and with "make check-lldb" and there was no MI related failure.
llvm-svn: 232380
Following 3 changes were made.
1. Test was assuming that function name will have () in the end. I dont know why lldb is generating function name like this but it looks like a bug. For this test, I have removed it.
2. Step instruction test was assuming that function call will not be the first instruction in the range of the line. This assumption failed with gcc. So I had fixed this.
3. Some minor adjustments with the line number.
Test with bot gcc and clang and all tests pass.
This test is still very fragile. We should be removing hardcoded line number.
llvm-svn: 232372
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
Abstracted away some POSIX-isms that caused MAKE to issue invalid
commands on Windows. Added a new force-include for the test
programs so that we can use platform-specific macros.
TestSharedLib now builds and cleans up on Windows, though the test
still fails some of the expectations.
Differential Revision: http://reviews.llvm.org/D8277
Patch by: Adrian McCarthy
Issue Tracker: http://llvm.org/pr21727
llvm-svn: 232220
The test cases in TestStubReverseConnect are using a socket connection
from python to lldb-server running on a remote target. To enable the
socket connection an adb port forwarding have to be set up when the
remote target is android.
Differential revision: http://reviews.llvm.org/D8319
llvm-svn: 232170
The value of some_values (pointer) expeced to start by 0x0 but nothing
requires that the first digit of the address be '0'.
This CL change the expectation to check only for a value starting with 0x.
llvm-svn: 232163
Android have more file descriptor opened by the shell what are inherited
to the process (different ones on device and on emulator).
Differential revision: http://reviews.llvm.org/D8299
llvm-svn: 232150
TestLldbGdbServer was failing because it always assumed AVX is available on
x86_64 Linux. This patch checks the target before asserting that AVX
registers are available.
llvm-svn: 232137
It was failing on gcc 4.8, only passing accidentally on clang 3.5
This patch improves the checking to make sure if fails in all cases
and then XFAILS
llvm-svn: 232092
Linux lldb-server Handle_m doesn't properly replace software breakpoints
with the original instructions. This test is added with expectedFailureLinux
Differential Revision: http://reviews.llvm.org/D8191
llvm-svn: 232091
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
If a test have very long name and the compiler specified with (a long)
full path then the name of the log file name can exceed 255 characters.
This change replace the full compiler path with just the compiler name
if the prior would cause a too long file name.
Differential revision: http://reviews.llvm.org/D8252
llvm-svn: 232024
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 allows not specify search path in each lldb-mi test. It makes tests easier.
This fix was requested by vharron.
All test pass on OS X.
Reviewers: vharron, clayborg
Subscribers: lldb-commits, vharron
Differential Revision: http://reviews.llvm.org/D8207
llvm-svn: 232019
Previously these test cases execute lldb-server on the host and run the
tests against it even if a remote platform was specified. With this CL
these tests always test the communication with an lldb-server instance
running on the target.
Differential revision: http://reviews.llvm.org/D8202
llvm-svn: 231922
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
Pavel Labath