Summary:
Saw this while reading some code in DynamicLoader classes. Looks like this has
been a FIXME since 2011 at least.
Test Plan: Run unit tests.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8558
llvm-svn: 232983
This was hardcoding some make rules instead of relying on
Makefile.rules, which was causing some of the logic to be
incorrect for Windows.
Patch by: Adrian McCarthy
Differential Revision: http://reviews.llvm.org/D8363
llvm-svn: 232974
Summary:
This has been discovered while experimenting with the gecko linker on android.
In general, assert()'ing on "user input" is a bad idea.
Test Plan: Run unit tests.
Reviewers: clayborg, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8495
llvm-svn: 232966
The time/date strings (like "6pm April 10, 1985") are interpreted as a local time but CFDateGetAbsoluteTime() returns time in UTC. It caused a problem when local time was UTC+0100 or more (0200, 0300 etc.):
```
======================================================================
FAIL: test_nsdate_with_dsym_and_run_command (TestDataFormatterObjC.ObjCDataFormatterTestCase)
Test formatters for NSDate.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 462, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 157, in test_nsdate_with_dsym_and_run_command
self.appkit_tester_impl(self.buildDsym,self.nsdate_data_formatter_commands)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 34, in appkit_tester_impl
commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 475, in nsdate_data_formatter_commands
substrs = ['1985-04','2011-01'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2146, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '2011-01' returns expected result
Config=x86_64-clang
======================================================================
FAIL: test_nsdate_with_dwarf_and_run_command (TestDataFormatterObjC.ObjCDataFormatterTestCase)
Test formatters for NSDate.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 479, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 163, in test_nsdate_with_dwarf_and_run_command
self.appkit_tester_impl(self.buildDwarf,self.nsdate_data_formatter_commands)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 34, in appkit_tester_impl
commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py", line 475, in nsdate_data_formatter_commands
substrs = ['1985-04','2011-01'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2146, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '2011-01' returns expected result
Config=x86_64-clang
```
llvm-svn: 232946
The latter is uint64_t beacuse lldb supports arbitrary pid/platforms
but in this case we're using it as return value for fork() which might
return -1 to the parent in case the syscall fails.
Differential Revision: http://reviews.llvm.org/D8491
llvm-svn: 232926
Summary:
Previously lldb-mi contains a stub for that but it didn't work and all CommanInterpreter's events were ignored.
This commit adds a handling of CommandInterpreter's events in lldb-mi.
Steps:
# Fix CMICmnLLDBDebugger::InitSBListener
# Add SBCommandInterpreter::EventIsCommandInterpreterEvent
# Exit on lldb::SBCommandInterpreter::eBroadcastBitQuitCommandReceived
All tests pass on OS X.
In further we can remove "quit" hack in lldb-mi.
Test Plan:
# Create start_script file:
```
target create ~/p/hello
b main
r
quit
```
# Run lldb-mi --interpreter
# Execute start_script file by following command:
```
-interpreter-exec console "command source start_script"
```
Log:
```
$ bin/lldb-mi --interpreter
(gdb)
-interpreter-exec console "command source start_script"
Executing commands in '/Users/IliaK/p/llvm/build_ninja/start_script'.
(lldb) target create ~/p/hello
Current executable set to '~/p/hello' (x86_64).
(lldb) b main
Breakpoint 1: where = hello`main + 29 at hello.cpp:12, address = 0x0000000100000e2d
(lldb) r
Process 1582 launched: '/Users/IliaK/p/hello' (x86_64)
(lldb) quit
^done
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=shlibs-added,shlib-info=[num="1",name="hello",dyld-addr="-",reason="dyld",path="/Users/IliaK/p/hello",loaded_addr="-",dsym-objpath="/Users/IliaK/p/hello.dSYM/Contents/Resources/DWARF/hello"]
...
=shlibs-added,shlib-info=[num="132",name="libDiagnosticMessagesClient.dylib",dyld-addr="0x7fff91705000",reason="dyld",path="/usr/lib/libDiagnosticMessagesClient.dylib",loaded_addr="0x7fff91705000"]
(gdb)
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x100000e2d",func="main",args=[{name="argc",value="1"},{name="argv",value="0x00007fff5fbffc88"}],file="hello.cpp",fullname="/Users/IliaK/p/hello.cpp",line="12"},thread-id="1",stopped-threads="all"
(gdb)<press Enter>
MI: Program exited OK
```
Reviewers: abidh, clayborg
Reviewed By: abidh
Subscribers: jingham, lldb-commits, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D8382
llvm-svn: 232891
Summary:
ComputeSupportExeDirectory relied on ComputeSharedLibraryDirectory which was
not always reliable. Using procfs seems to be the best way to deal with it on
Linux (since it's already done on Android, might as well merge it).
Reviewers: ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8511
llvm-svn: 232883
Test Plan: No tests, this is just a debug logging function.
Reviewers: tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8453
llvm-svn: 232815
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
This creates a new top-level folder called Initialization which
is intended to hold code specific to LLDB system initialization.
Currently this holds the Initialize() and Terminate() functions,
as well as the fatal error handler.
This provides a means to break the massive dependency cycle which
is caused by the fact that Debugger depends on Initialize and
Terminate which then depends on the entire LLDB project. With
this structure, it will be possible for applications to invoke
lldb_private::Initialize() directly, and have that invoke
Debugger::Initialize.
llvm-svn: 232768
Summary:
sc.block->AppendVariables(...) returns 0 if there are no arguments or local
variables, but we still need to check for global variables.
Test Plan:
```
$ cat test.cpp
int i;
int main() {
}
$ lldb test -o 'b main' -o r
(lldb) script
>>> print lldb.frame.FindValue('i', lldb.eValueTypeVariableGlobal)
(int) i = 0 # as opposed to "No value"
```
Reviewers: jingham, ovyalov, vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8464
llvm-svn: 232767
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
Some application on Linux an all application on android close stdout and
stderr during the libc exit stage. Previously the master file descriptor
of the pseudo terminal used to communicate with the inferior was closed
on an EOF causing a race condition and a possible SIGHUP on process
exit. After this change the master file descriptor will be closed by the
destructor of the GDBRemoteCommunicationServerLLGS class.
Differential revision: http://reviews.llvm.org/D8436
llvm-svn: 232724
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
Specifically, there were some functions for converting enums
to strings and a function for matching a string using a specific
matching algorithm. This moves those functions to more appropriate
headers in lldb/Utility and updates references to include the
new headers.
llvm-svn: 232673
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
This moves the conversion of the open options to the target platform. On mac fcntl.h has different values for O_CREAT and O_TRUNC than on linux so by transmitting the standardized lldb open options we can correctly convert them on the target platform.
Test Plan:
On linux:
lldb-server p --listen *:1234
On mac:
lldb
platform select remote-linux
platform connect connect://ip-of-linux-box:1234
target create ~/path/to/linux/binary
b main
process launch
Binary is successfully pushed to linux remote, process successfully launches and break in the main method.
Differential Revision: http://reviews.llvm.org/D8395
llvm-svn: 232634
In android a .note.android.ident section header is added to the elf
files to provide information for the debuggers that it is an android
specific module. This CL add logic to parse it out from the elf files
and set the module specification based on it.
Differential revision: http://reviews.llvm.org/D8377
llvm-svn: 232625
Summary:
Previously lldb-mi can also act as a driver like normal lldb. It needed a lot
of redundant code in the lldb-mi for that. I think that if a user wants command
line lldb driver then he/she should use the lldb for it. This change will cleanup
the code a lot. When this change goes in, it will allow us to remove some more
redundant code too.
All tests pass on Linux. Did some sanity testing on command line and with eclipse.
Reviewers: ki.stfu
Reviewed By: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8381
llvm-svn: 232621
Summary:
This is initial implementation of assembly profiler which only scans prologue/epilogue assembly instructions to create CFI instructions.
Reviewers: clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D7696
llvm-svn: 232619
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
This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
# Fix CommandInterpreter.Broadcaster name (it should be the same as CommandInterpreter::GetStaticBroadcasterClass())
# Prevent the same error in Process.Broadcaster
# Fix SBCommandInterpreter::GetBroadcasterClass (it should call CommandInterpreter::GetStaticBroadcasterClass(), was Communication::GetStaticBroadcasterClass())
llvm-svn: 232500
Some linux kernel reports a watchpoint hit after single stepping even
when no watchpoint was hit. This CL looks for a watchpoint which was hit
and reports a stop by trace if it haven't found any.
Differential revision: http://reviews.llvm.org/D8081
llvm-svn: 232482
The order of libraries passed to the linker didn't work under linux (you
need the llvm libraries first, then the lldb libraries). I modelled this
after clang's setup here. Seemed simple enough to just be consistent.
llvm-svn: 232461
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
Most of lldb-mi files have comments about environement, copyright etc which were neither needed nor uptodate.
This commit removes those comments.
llvm-svn: 232396
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
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
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
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
Summary:
This patch fixes SDK selection in the following case:
```
platform select remote-ios --sysroot "/Users/IliaK/Library/Developer/Xcode/iOS DeviceSupport/8.1.2 (12B440)" --build 12B440 --version 8.1.2
target create --arch arm64 "~/Project1.app"
```
Currently the lldb selects a first SDK version (in name order) in directory and then updates it after the device is connected. This approach ignores user's arguments and actually "platform select" command doesn't make sense.
After this patch, lldb takes a SDK which matches to user's arguments.
Reviewers: jasonmolenda, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jasonmolenda, aemerson
Differential Revision: http://reviews.llvm.org/D8249
llvm-svn: 232017
This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly.
Differential Revision: http://reviews.llvm.org/D8186
llvm-svn: 231966
In http://reviews.llvm.org/D7880 the initialization for LLGS was separated out so that LLGS could initialize only the components it needs to. This further reduces the set of components initialized for LLGS.
Differential Revision: http://reviews.llvm.org/D8112
llvm-svn: 231964
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:
ProcessGDBRemote::AsyncThread nuked its own thread handle upon exiting. This prevented the main
thread from joining it correctly in StopAsyncThread. I address this by moving the Reset() call to
StopAsyncThread, after the join.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8218
llvm-svn: 231915
kernel debug session, instead of issuing a warning (which on one ever
sees), drop the user-specified kernel binary Module from the target and
try to discover the correct one dynamically.
<rdar://problem/19450329>
llvm-svn: 231885
This improves the instructions for checking out LLDB, adds
more links to LLVM instructions, and more explicitly calls out
when we differ from the style guide.
Also updates the clang-format configuration file to correctly
reflect a 120 column limit.
Reviewed by: Jim Ingham
Differential Revision: http://reviews.llvm.org/D8222
llvm-svn: 231884
After http://reviews.llvm.org/D8133 landed as r231550 process launch on remote platform stopped working.
This adds Debugger::InitializeForLLGS and tracks whether one or both of Initialize and InitializeForLLGS have been called, calling only the corresponding lldb_private::Terminate* methods as necessary. Since lldb_private::Terminate calls lldb_private::TerminateForLLGS, the latter method may be called twice if Initialize was called for both however the terminate methods ensure they are only called once after being initialized.
This still maintains the reduced binary size, though it does now technically link in lldb_private::Terminate on lldb-server even though this should never be called.
This should resolve the issue raised in http://reviews.llvm.org/D8133 where Debugger::Terminate assumed that there were 0 references to debugger and terminated early.
Differential Revision: http://reviews.llvm.org/D8183
llvm-svn: 231808
Summary:
Fix a comment for ValueObject::GetValueDidChange after r231526.
This fix was requested by @jingham.
Reviewers: jingham, ki.stfu
Reviewed By: ki.stfu
Subscribers: lldb-commits, jingham
Differential Revision: http://reviews.llvm.org/D8206
llvm-svn: 231804
The issue can happen if you strip your main executable and then run an expression and it would fail to find the stripped symbol and it would then not be able to make the function call. The issue was fixed by doing our normal FindFunctions call.
<rdar://problem/20072750>
llvm-svn: 231667
Thic change have effect wehn the AVX registers aren't available with
reporting the count of user registers without them.
Differential revision: http://reviews.llvm.org/D8111
llvm-svn: 231638
Linux configure+make builds have ~175 tests failing that aren't
failing in cmake builds. The tests have error messages like
"'a.out' doesn't contain the architecture x86-64" ObjectFileELF
plugin wasn't loaded when this message was output.
I found ScriptInterpreterPython::InitializePrivate() is calling
Debugger::Terminate(), which terminates ObjectFileELF (and lots
of other stuff) setup earlier in the InitializeForLLGS.
So I moved python Init/Term from Init/TermForLLGS to Init/Term
llvm-svn: 231550
This means you can set an expression prefix file with:
(lldb) settings set target.expr-prefix /tmp/to/prefix.txt
And you can run an expression and modify your expression prefix file in another editor without having to type:
(lldb) settings set target.expr-prefix /tmp/to/prefix.txt
again...
<rdar://problem/12155942>
llvm-svn: 231535
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:
This patch includes:
* Fix -var-create command for global/static variables
* Fix -var-update command: remove m_strValueName/m_eVarInfoFormat/m_bValueChanged{Array,Composite,Normal}Type; clean CMICmdCmdVarUpdate::Execute and CMICmdCmdVarUpdate::Acknowledge; improve CMICmdCmdVarUpdate::MIFormResponse; Complete the value after -var-create using the CMICmdCmdVarCreate::CompleteSBValue to get SBValue::GetValueDidChange work.
* Add non-constant version of CMICmnLLDBDebugSessionInfoVarObj::GetValue
* Add MiVarTestCase.test_lldbmi_var_update test
All tests pass on OS X.
Reviewers: abidh, emaste, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, emaste, clayborg, abidh
Differential Revision: http://reviews.llvm.org/D8110
llvm-svn: 231525
This removes Host::Backtrace from the codebase, and changes all
call sites to use llvm::sys::PrintStackTrace(). This makes the
functionality available for all platforms, and even for platforms
which currently had a supported implementation of Host::Backtrace,
this patch should enable richer information in stack traces, such
as file and line number information, as well as giving it the
ability to unwind through inlined functions.
llvm-svn: 231511
- use a hardcoded formatter to match all vector types, and make it so that their element type is taken into account when doing default formatting
- special case a vector of char to display byte values instead of characters by default
Fixes the test failures Ilia was seeing
llvm-svn: 231504
Summary:
I'm not sure that this failure should be fixed by modifying this test.
It seems strange for me that the only one type vUInt8 is printed with '0x' prefix.
This patch fixes the following error:
```
======================================================================
FAIL: test_with_dsym_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 456, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 21, in test_with_dsym_and_run_command
self.data_formatter_commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 68, in data_formatter_commands
'(vBool32) valueBool32 = (0, 1, 0, 1)'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2100, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '(vUInt8) valueU8 = ('\x01', '\0', '\x04', '\0', '\0', '\x01', '\0', '\x04', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0')' returns expected result
Config=x86_64-clang
======================================================================
FAIL: test_with_dwarf_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 473, in wrapper
return func(self, *args, **kwargs)
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 28, in test_with_dwarf_and_run_command
self.data_formatter_commands()
File "/Users/IliaK/p/llvm/tools/lldb/test/functionalities/data-formatter/rdar-10642615/Test-rdar-10642615.py", line 68, in data_formatter_commands
'(vBool32) valueBool32 = (0, 1, 0, 1)'])
File "/Users/IliaK/p/llvm/tools/lldb/test/lldbtest.py", line 2100, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '(vUInt8) valueU8 = ('\x01', '\0', '\x04', '\0', '\0', '\x01', '\0', '\x04', '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0')' returns expected result
Config=x86_64-clang
----------------------------------------------------------------------
```
Reviewers: granata.enrico, zturner, clayborg
Subscribers: clayborg, lldb-commits, zturner, granata.enrico
Differential Revision: http://reviews.llvm.org/D8102
llvm-svn: 231490
Previously it was initialized by ProcessLinux but lldb-server don't
contain ProcessLinux anymore so it have to be initialized by
NativeProcessLinux also.
Differential revision: http://reviews.llvm.org/D8080
llvm-svn: 231482
Summary:
starting a debug session on linux with -o "process launch" lldb parameter was failing since
Target::Launch (in sychronous mode) is expecting to be able to receive public process events.
However, PlatformLinux did not set up event hijacking on process launch, which caused these
events to be processed elsewhere and left Target::Launch hanging. This patch enables event
interception in PlatformLinux (which was commented out).
Upon enabling event interception, I noticed an issue, which I traced back to the inconsistent
state of public run lock, which remained false even though public and private process states were
"stopped". I addressed this by making sure the run lock is "stopped" upon exit from
WaitForProcessToStop (which already had similar provisions for other return paths).
Test Plan: This should fix the intermittent TestFormats failure we have been experiencing on Linux.
Reviewers: jingham, clayborg, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8079
llvm-svn: 231460
Unlike GDB, we tackle the problem of representing vector types in different styles by having a synthetic child provider that recognizes the format you're trying to apply to the variable, and coming up with the right type and number of child values to match that format
This makes for a more compact representation and less visual noise
Fixes rdar://5429347
llvm-svn: 231449
This is a temporary fix until a more comprehensive fix can be made for finding functions that we call in expressions.
We find "NSLog" in ClangExpressionDeclMap::FindExternalVisibleDecls() in after a call to target->GetImages().FindFunctions(...). Note that there are two symbols: NSLog from CFNetwork which is not external, and NSLog from Foundation which _is_ external. We do something with the external symbol with:
if (extern_symbol)
{
AddOneFunction (context, NULL, extern_symbol, current_id);
context.m_found.function = true;
}
Then later we try to lookup the _Z5NSLogP8NSStringz name and we don't find it so we call ClangExpressionDeclMap::GetFunctionAddress() with "_Z5NSLogP8NSStringz" as the name and the sc_list_size is zero at the "if" statement at line 568 because we don't find the mangled name and we extract the basename "NSLog" and call:
FindCodeSymbolInContext(ConstString(basename), m_parser_vars->m_sym_ctx, sc_list);
sc_list_size = sc_list.GetSize();
and we get a list size of two again, and we proceed to search for the symbol again, this time ignoring the external vs non-external-ness of the symbols that we find. This fix ensures we prioritize the external symbol until we get a real fix from Sean Callanan when he gets back to make sure we don't do multiple lookups for the same symbol we already resolved.
<rdar://problem/19879282>
llvm-svn: 231420
Summary:
LLDB driver was simply tacking quotes around the strings in lldb commands, hoping that will work.
This changes it to properly escape quotes and backslashes.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8083
llvm-svn: 231394
operator in addition to the vendor-extension DW_OP_GNU_push_tls_address.
clang on PS4 and Darwin will be emitting the standard opcode
as of r231286 via http://reviews.llvm.org/D8018
Behavior of this standard opcode is the same as
DW_OP_GNU_push_tls_address.
<rdar://problem/20043195>
llvm-svn: 231342
We would like it if LLDB never crashed, especially if we never caused LLDB to crash
On the other hand, having assertions can sometimes be useful
lldbassert(x) is the best of both worlds:
- in debug builds, it turns into a regular assert, which is fine because we don't mind debug LLDB to crash on development machines
- in non-debug builds, it emits a message formatted just like assert(x) would, but then instead of crashing, it dumps a backtrace, suggests filing a bug, and keeps running
llvm-svn: 231310
Setting it from the Target architecture cause problems when the target
archiutecture is filled just by examining the executable because in that
case the OS isn't set.
Differential revision: http://reviews.llvm.org/D8035
llvm-svn: 231234
The deadlock occurred when the Attach or the Launch operation failed for
any reason.
Differential revision: http://reviews.llvm.org/D8030
llvm-svn: 231231
Summary:
Symbol table generation code was failing to take into account the debug symbols because
the object file was looking only into its own section list when doing the generation, even though
the debug symbols from another object file were correctly detected and loaded by the
SymbolVendor. This changes the code to use the unified section list, which fixes this problem.
Test Plan:
I do not intend do submit this yet since it causes (or more like, exposes) the issue
in D7884, but I wanted to put this out here, so that anyone who wants to take a look at it can do
so. (And I also wanted to know if this is the right approach to the problem :).
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7913
llvm-svn: 231229
Summary:
Symbols in ELF files can be versioned, but LLDB currently does not understand these. This problem
becomes apparent once one loads glibc with debug info. Here (in the .symtab section) the versions
are embedded in the name (name@VERSION), which causes issues when evaluating expressions
referencing memcpy for example (current glibc contains memcpy@@GLIBC_2.14 and
memcpy@GLIBC_2.2.5).
This problem was not evident without debug symbols as the .dynsym section
stores the bare names and the actual versions are present in a separate section (.gnu.version_d),
which LLDB ignores. This resulted in two definitions of memcpy in the symbol table.
This patch adds support for storing annotated names to the Symbol class. If
Symbol.m_contains_linker_annotations is true then this symbol is annotated. Unannotated name can
be obtained by calling StripLinkerAnnotations on the corresponding ObjectFile. ObjectFileELF
implements this to strip @VERSION suffixes when requested. Symtab uses this function to add the
bare name as well as the annotated name to the name lookup table.
To preserve the size of the Symbol class, I had to steal one bit from the m_type field.
Test Plan:
This fixes TestExprHelpExamples.py when run with a glibc with debug symbols. Writing
an environment agnostic test case would require building a custom shared library with symbol
versions and testing symbol resolution against that, which is somewhat challenging.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8036
llvm-svn: 231228
Ilia K