On Windows, you need to call WSAStartup() before making any socket
calls, and WSACleanup() before you shutdown. This wasn't being
done, so all of the socket tests were failing. This fixes
that, which brings the unit test suite to a fully working state
on Windows.
llvm-svn: 232247
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
This makes the directory structure mirror the canonical LLVM
directory structure for a gtest suite.
Additionally, this patch deletes the xcode project. Nobody
is currently depending on this, and it would be better to have
gtest unit tests be hand-maintained in the Xcode workspace
rather than using this python test runner. Patches to that
effect will be submitted as followups.
llvm-svn: 232211
Previously it would only regenerate LLDBWrapPython.cpp if one of
the .i files changed, or if lldb.swig changed. This patch also
makes it depend on the rest of the *.swig files, so that if any
of them changes it regenerates the CMake.
llvm-svn: 232175
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
* On Android (at least on platfrom-21 x86) the dynamic linker reports the
executable with its full path
* Use the platform path of the executable when storing it into the cache
(used to identify the SO entry for the executable) as this is the path
what will be reported by the dynamic linker. If the platform path isn't
set (local debugging) then it falls back to the normal file path.
Differential revision: http://reviews.llvm.org/D8296
llvm-svn: 232158
Fill in the missing part of the architecture in GetProcessInfo from the
HostArchitecture (e.g. Environment).
Differential revision: http://reviews.llvm.org/D8292
llvm-svn: 232157
The file path is currently required on android because the executables
only contain the name of the system libraries without their path. This
CL add an extra field to the qModuleInfo packet to return the full path
of a modul and add logic to locate a shared module on android.
Differential revision: http://reviews.llvm.org/D8221
llvm-svn: 232156
This CL change the logic used to terminate the monitor thread of
NativeProcessLinux to use a signal instead of pthread_cancel as
pthread_cancel is not supported on android.
Differential revision: http://reviews.llvm.org/D8205
llvm-svn: 232155
Previously it was fetched only if the architecture isn't valid, but the
architecture can be valid without containing all information about the
current target (e.g. missing os).
Differential revision: http://reviews.llvm.org/D8057
llvm-svn: 232153
Summary:
SymbolFileDWARF was not respecting the include_inlines argument in function lookup in all code
paths. This resulted in an attempt to call an inlined function during expression evaluation,
which is impossible, and usually resulted in a segfault in the inferior. This patch makes sure
include_inlines is respected in all code paths.
Reviewers: clayborg
Subscribers: lldb-commits, sivachandra
Differential Revision: http://reviews.llvm.org/D8286
llvm-svn: 232151
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
This works by creating a command backed by a class whose interface should - at least - include
def __init__(self, debugger, session_dict)
def __call__(self, args, return_obj, exe_ctx)
What works:
- adding a command via command script add --class
- calling a thusly created command
What is missing:
- support for custom help
- test cases
The missing parts will follow over the next couple of days
This is an improvement over the existing system as:
a) it provides an obvious location for commands to provide help strings (i.e. methods)
b) it allows commands to store state in an obvious fashion
c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-)
llvm-svn: 232136
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
This variable "g_debugger_name" is not used anywhere. It also causes a warning.
I was first going to change its type to fix the warning then noticed that it
is not being used. So removing it.
Committed as Obvious.
llvm-svn: 232043
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
Ed Maste