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
Not checking for this flags caused lldb-mi to issue stop notification when target
has started running again. It also tried to get stack when target was running and
this caused randon failure.
Approved in http://lists.cs.uiuc.edu/pipermail/lldb-dev/2015-March/006953.html
llvm-svn: 232370
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
A recent refactor had introduced a bug where if you escaped a
character, the rest of the string would get processed incorrectly.
This patch fixes that bug and adds some unit tests for Args.
llvm-svn: 232288
Sigh. There's really not a good alternative until we decouple
python from lldb better. The only way the build works right now
is by having every executable link against every LLDB library.
This causes implicit transitive link dependencies on the union
of everything that LLDB brings in. Which means that if all we
want is one header file from interpreter, we have to bring in
everything, including everything that everything depends on,
which means python.
There's outstanding efforts to address this, but it's not yet
complete. So until then, this is all we can do.
llvm-svn: 232287
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
Hafiz Abid Qadeer