4-core CPUs have a hard time keeping up with the number of debuggers
we were simultaneously spawning. This leads to a timeout, which
leaves processes hanging around in "suspended mode", which can't be
killed with signals.
llvm-svn: 249421
Rename the python source file for DataFormatterOSTypeTestCase to match
the purpose of the test and to avoid a name conflict with
DataFormatterBoolRefPtr. The name conflict caused a race condition in
the test runner what we have to address separately.
llvm-svn: 249407
Summary:
When `module_spec.GetFileSpec().GetDirectory().AsCString()` returned a `nullptr` this line caused a segmentation fault:
`std::string module_directory = module_spec.GetFileSpec().GetDirectory().AsCString()`
Some context:
I was remote debugging an executable built with Clang in an Ubuntu VM on my Windows machine using lldb-mi. I copied the executable and nothing else from the Ubuntu VM to the Windows machine.
Then started lldb-server in the Ubuntu VM:
```
./bin/lldb-server gdbserver *:8888 -- /home/enlight/Projects/dbgmits/build/Debug/data_tests_target
```
And ran `lldb-mi --interpreter` on Windows with the following commands:
```
-file-exec-and-symbols C:\Projects\data_tests_target
-target-select remote 192.168.56.101:8888
-exec-continue
```
After which the segmentation fault occurred at the aforementioned line. Inside this method `module_spec.GetFileSpec()` returns an empty `FileSpec` (no dir, no filename), while `module_spec.GetSymbolFileSpec().GetFilename()` returns `"libc-2.19.so"`.
Patch thanks to Vadim Macagon.
Reviewers: brucem, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13201
llvm-svn: 249387
SUMMARY:
This patch includes:
1. Emulation of prologue/epilogue and branch instructions for microMIPS.
2. Setting up alternate disassembler (to be used for microMIPS).
So there will be two disassembler instances, one for microMIPS and other for MIPS.
Appropriate disassembler will be used based on the address class of instruction address.
3. Some of the branch instructions does not have fixed sized delay slot, that means delay slot instruction can be of 2-byte or 4-byte.
For this "m_next_inst_size" has been introduced which stores the size of next instruction (i.e size of delay slot instruction in case of branch).
This can be used wherever the size of next instruction is required.
4. A minor change to use mips32 register names instead of mips64 names.
Reviewers: clayborg, tberghammer
Subscribers: mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits
Differential Revision: http://reviews.llvm.org/D13282
llvm-svn: 249381
This patch adds a new command 'language renderscript allocation list' for printing the details of all loaded RS allocations.
In order to work out this information lldb JITs the runtime for the data it wants.
This has a penalty of a couple seconds latency, so is only done once for each allocation and the results cached.
If the user later wants to recalculate this information however, they can force lldb to do so with the --refresh flag.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, dean, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D13247
llvm-svn: 249380
Added the ability to specify if an attach by name should be synchronous or not in SBAttachInfo and ProcessAttachInfo.
<rdar://problem/22821480>
llvm-svn: 249361
When the readline target exists (only for non-Android Linux currently),
ensure that target is made a dependency of the finish_swig python-wrap-up
steps. This ensures it is built when building the lldb target.
Fixes:
https://llvm.org/bugs/show_bug.cgi?id=25038
llvm-svn: 249256
The concept here is that languages may have different ways of communicating
results. In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results). Materializer was tied to one specific model of result handling.
Instead, now UserExpressions can register their own handlers for the result
variables they inject. This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.
PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated. It can also be used to touch
persistent variables if need be, updating language-specific state. The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.
The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.
llvm-svn: 249233
TestDiamond and TestSBValueCast were due to a bug in clang. That
bug has been fixed, so xfail is removed. However fixing that bug
exposed another bug in clang, which is not yet fixed. That bug
causes one test to start crashing, and another to fail unexpectedly
so the status of those tests is updated as well.
llvm-svn: 249208
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language
llvm-svn: 249185
* Use .ARM.exidx as a fallback unwind plan for non-call site when the
instruction emulation based unwind failed.
* Work around an old compiler issue where the compiler isn't sort the
entries in .ARM.exidx based on their address.
* Fix unwind info parsing when the virtual file address >= 0x80000000
* Fix bug in unwind info parsing when neither lr nor pc is explicitly
restored.
Differential revision: http://reviews.llvm.org/D13380
llvm-svn: 249119
The ClangExpressionVariable::CreateVariableInList functions looked cute, but
caused more confusion than they solved. I removed them, and instead made sure
that there are adequate facilities for easily adding newly-constructed
ExpressionVariables to lists.
I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.
llvm-svn: 249095
This patch adds a --start option to the lldb-mi -exec-run command for
getting process stopped at entry point after launch. It is equivelent
to the -s option in the lldb command line interpreter:
process launch -s
and is therefore not supported on all hosts and/or targets. To check
if the --start option is supported, see if the corresponding feature
"exec-run-start-option" is in the list of options reported by the lldb-mi
"-list-features" command.
Patch from engineer.developer@gmail.com (Kirill Lapshin)
Reviewed by: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12977
llvm-svn: 249072
Currently, it only supports Objective-C - C++ types can be looked up through debug info via 'image lookup -t', whereas ObjC types via this command are looked up by runtime introspection
This behavior is in line with type lookup's behavior in Xcode 7, but I am definitely open to feedback as to what makes the most sense here
llvm-svn: 249047
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the accessor functions to pickup the value from m_scalar of RegisterValue which is zero.
In this patch byte size and byte order of register value is set at the time of setting the value of the register.
llvm-svn: 249020
Run the getprop command with AdbClient::Shell instead of
Platform::RunShellCommand because getting the output from getprop
with Platform::RunShellCommand have some (currently unknown) issues.
llvm-svn: 249014
Change the way we detect if we have to place a thumb breakpoint instead
of an arm breakpoint in the case when no symbol table or mapping symbols
are available. Detect it based on the LSB of the FileAddress instead of
the LSB of the LoadAddress because the LSB of the LoadAddress is already
masked out.
llvm-svn: 249013
The hack is there to work around an incorrect load address reported
by the android linker on API 21 and 22 devices. This CL restricts the
hack to those android API levels.
Differential revision: http://reviews.llvm.org/D13288
llvm-svn: 249012
Summary:
After a developer builds LLDB from source on Windows (assuming they've built it with Python support enabled), they may be somewhat flustered when it fails to launch with a cryptic error.
{F890625}
This happens because Windows can't find python27.dll (or python27_d.dll in case LLDB was built in debug mode). Many developers may have previously installed a release build of Python 2.7 and will not notice anything is amiss when they run a release build of LLDB because Windows will load the python27.dll from one of the system directories or `PATH` (rather than the one that the LLDB build instructions tell them to build). The issue tends to be more pronounced with debug builds of LLDB, since fewer developers probably have python27_d.dll sitting in one of the Windows system directories.
To ensure Windows loads the correct custom built Python DLL when launching LLDB I've added a post-build event that copies the relevant DLL (based on the LLDB build configuration) from `PYTHON_HOME` to the directory in which the LLDB executable is generated.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13237
llvm-svn: 248992
Summary:
Previously `CMAKE_BUILD_TYPE` was used to determine whether to link in `python27.lib` or `python27_d.lib`, unfortunately this only works reliably when using a CMake generator that generates a single build configuration (e.g. Ninja). The Visual Studio CMake generator generates four build configurations at once (`Debug`, `Release`, `RelWithDebInfo`, `MinSizeRel`), so if `CMAKE_BUILD_TYPE` is set to `Debug` all four build configurations end up linking in `python27_d.lib`, this is clearly undesirable.
To ensure that the correct Python lib is used for each build configuration the value of `PYTHON_LIBRARY` is now determined using generator expressions that evaluate to either the debug or release Python lib. The values of `PYTHON_EXECUTABLE` and `PYTHON_DLL` are now likewise determined using generator expressions.
Note that these changes only apply to the Windows build.
Patch by Vadim Macagon. Thanks!
Reviewers: zturner, brucem
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13234
llvm-svn: 248991
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 248985
This is meant to support languages that have a scripting mode with top-level code that acts as global
For now, this flag only controls whether 'frame variable' will attempt to treat globals as locals when within such a function
llvm-svn: 248960
Part of https://llvm.org/bugs/show_bug.cgi?id=25002
In writing the new process_control test included here,
I discovered that the scenario would hang indefinitely,
bypassing the timeout logic.
This fixes the indefinite hang, converting an error
in the new test to a failure. I'll fix the failure
next. This one was heinous enough to fix on its own,
though.
llvm-svn: 248936
Todd Fiala