Instead check what languages are supported for expressions; use C if available,
but otherwise pick one of the supported languages.
This can be overridden using the target settings.
<rdar://problem/22290878>
llvm-svn: 249864
Summary:
Add dependencies to the custom commands so that they get
re-executed as needed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13580
llvm-svn: 249860
Summary:
EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't
implemented or used anywhere, so remove them from the Hexagon and POSIX
Dynamic Loaders as well as the FreeBSD process.
Reviewers: clayborg, labath, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D13581
llvm-svn: 249840
Summary:
Log files produced by dotest have names derived from the test name, and this produces errors in
case we have multiple tests with the same name. Additionally, it's good if the test name explains
what the test is testing (which it clearly doesn't do well if there are multiple tests with
identical names). This commit makes the presence of such tests a hard error.
Reviewers: tberghammer, zturner
Subscribers: iancottrell, lldb-commits
Differential Revision: http://reviews.llvm.org/D13588
llvm-svn: 249828
We want to skip these tests when the target platform is darwin, not
when the host because they have to be enabled in case of darwin ->
android
llvm-svn: 249825
Summary:
This is Darwin only.
The symbol defined by ${LLDB_VERS_GENERATED_FILE} is used by
source/lldb.cpp, so anything that uses lldb.cpp (which is in
lldbBase) should also have the generated symbol. This means
that the entire process can be centralized within source/CMakeLists.txt
where lldbBase is constructed.
Additionally, the custom command should have dependencies on the
project file as well as the generation script so that if either
changes, the version file is correctly re-generated and everything
is re-linked appropriately.
* cmake/LLDBDependencies.cmake: Remove everything related to
the generated version file from here.
* source/CMakeLists.txt: On Darwin, add the generated version
file to the sources that make up lldbBase. Also, create a
custom target and make lldbBase depend on it to re-generate
the generated file as needed.
* source/API/CMakeLists.txt: Don't need to build the generated
version file here or use it to control linking against swig_wrapper.
* tools/lldb-server/CMakeLists.txt: Likewise.
Reviewers: dawn, sas, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13552
llvm-svn: 249806
when they introduced android testsuite regressions. Pavel has run the
testsuite against the updated patch and it completes cleanly now.
The original commit message:
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
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: 249755
This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases.
llvm-svn: 249747
The <no-defaults> special entry will prevent that specific directory's excludes from
receiving the global default source excludes. This allows overriding the global default
in a specific instance, simplifying the syntax for that case.
llvm-svn: 249705
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
Summary:
Previously CMake would display messages like these:
```
-- LLDB Found PythonExecutable: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python_d.exe>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python.exe>
-- LLDB Found PythonLibs: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib>
-- LLDB Found PythonDLL: $<$<CONFIG:Debug>:C:/Projects/Python-2.7.9-bin/x64/python27_d.dll>$<$<NOT:$<CONFIG:Debug>>:C:/Projects/Python-2.7.9-bin/x64/python27.dll>
```
This patch makes the messages look like this:
```
-- LLDB Found PythonExecutable: C:/Projects/Python-2.7.9-bin/x64/python.exe and C:/Projects/Python-2.7.9-bin/x64/python_d.exe
-- LLDB Found PythonLibs: C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib and C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib
-- LLDB Found PythonDLL: C:/Projects/Python-2.7.9-bin/x64/python27.dll and C:/Projects/Python-2.7.9-bin/x64/python27_d.dll
```
I've also added checks to ensure the messages are actually accurate, as in check that the files actually exist before claiming they've been found. If any of the files are missing Python integration will be disabled for the build.
Patch by Vadim Macagon. Thanks!
Reviewers: brucem, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13520
llvm-svn: 249671
Summary: This change fixes pr24916. As associated test has been added.
Reviewers: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13224
llvm-svn: 249629
When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're running
SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes
this.
Based on patch from scallanan@apple.com
Reviewed by: dawn
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13267
llvm-svn: 249624
If a string contained characters outside the ASCII range, lldb-mi would
print them as hexadecimal codes. This patch fixes this behaviour by
converting to UTF-8 instead, by having lldb-mi use registered type
summary providers, when they are available. This patch also fixes
incorrect evaluation of some composite types, like std::string, by
having them use a type registered type summary provider.
Based on patch from evgeny.leviant@gmail.com
Reviewed by: ki.stfu, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13058
llvm-svn: 249597
Introduce the notion of Language-based formatter prefix/suffix
This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values
This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this
llvm-svn: 249587
Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.
It also adds override where virtual was previously
missing.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13503
llvm-svn: 249564
Summary:
The StackUsesFrames and FunctionCallsChangeCFA virtual functions
aren't used anywhere and aren't overridden by anything.
They were introduced when the ABISysV_ppc* code was added and weren't
used at the time. The review for the commit that added them can be
found at http://reviews.llvm.org/D5988
The commit comment notes that backtraces don't yet work:
Backtraces don't work. This is due to PowerPC ABI using a
backchain pointer in memory, instead of a dedicated frame
pointer register for the backchain.
So there is a possibility these were added with the intent of using
them in the future.
Reviewers: clayborg, jingham, jhibbits, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13506
llvm-svn: 249563
Previously we haven't cleaned up the working directory we created on
the remote platform and because of it we run out of storage on some
android device/emulator (caused by the 2x increase of the number of
test cases because of dwo).
llvm-svn: 249541
dwo symbol files are generated when code compiled with the "-gsplit-dwarf"
command option (https://gcc.gnu.org/wiki/DebugFission). This CL modifies
the test system to run tests with inferiors compile with the "-gsplit-dwarf"
Differential revision: http://reviews.llvm.org/D13300
llvm-svn: 249530
Summary: This was deprecated and removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13463
llvm-svn: 249452
Go tests fail on Ubuntu 14.04's go1.2.1. This change puts a minimum
go version in the skipUnlessGoInstalled() decorator of go1.3.0.
Go maintainers are encouraged to modify as needed. For now this fixes
failing tests on Ubuntu 14.04 x86_64 buildbots with stock distro go installed.
llvm-svn: 249446
Summary: We were missing the symbol for the version number.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13271
llvm-svn: 249434
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
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
.ARM.exidx/.ARM.extab sections contain unwind information used on ARM
architecture from unwinding from an exception.
Differential revision: http://reviews.llvm.org/D13245
llvm-svn: 248903
This test was timing out because the test inferior was forking a child, which was not terminated
correctly. The test contained provisions to terminate this child, but these were no longer
working. The idea was to wake up upon receiving SIGTERM and then kill the child. However, this
was failing because the test first tried to use SIGHUP, which ended up killing the inferior.
Fix: make sure we catch SIGHUP also.
llvm-svn: 248889
Currently most of the test files have a separate dwarf and a separate
dsym test with almost identical content (only the build step is
different). With adding dwo symbol file handling to the test suit it
would increase this to a 3-way duplication. The purpose of this change
is to eliminate this redundancy with generating 2 test case (one dwarf
and one dsym) for each test function specified (dwo handling will be
added at a later commit).
Main design goals:
* There should be no boilerplate code in each test file to support the
multiple debug info in most of the tests (custom scenarios are
acceptable in special cases) so adding a new test case is easier and
we can't miss one of the debug info type.
* In case of a test failure, the debug symbols used during the test run
have to be cleanly visible from the output of dotest.py to make
debugging easier both from build bot logs and from local test runs
* Each test case should have a unique, fully qualified name so we can
run exactly 1 test with "-f <test-case>.<test-function>" syntax
* Test output should be grouped based on test files the same way as it
happens now (displaying dwarf/dsym results separately isn't
preferable)
Proposed solution (main logic in lldbtest.py, rest of them are test
cases fixed up for the new style):
* Have only 1 test fuction in the test files what will run for all
debug info separately and this test function should call just
"self.build(...)" to build an inferior with the right debug info
* When a class is created by python (the class object, not the class
instance), we will generate a new test method for each debug info
format in the test class with the name "<test-function>_<debug-info>"
and remove the original test method. This way unittest2 see multiple
test methods (1 for each debug info, pretty much as of now) and will
handle the test selection and the failure reporting correctly (the
debug info will be visible from the end of the test name)
* Add new annotation @no_debug_info_test to disable the generation of
multiple tests for each debug info format when the test don't have an
inferior
Differential revision: http://reviews.llvm.org/D13028
llvm-svn: 248883
The timeout mechanism has been implemented in python,
so there is no more dependence on external utilities
for timing out an inferior dotest.py process.
Platform-specific bits are implemented for POSIX-like
and Windows platforms. There is a small class named
ProcessHelper in process_control.py that needs to be
overridden for platforms that fall outside of the
POSIX-like and Windows platforms.
See http://reviews.llvm.org/D13124 for more details.
llvm-svn: 248834
On android when debugging an apk we run lldb-server as application user
because the sell user (on non-rooted device) can't attach to an
application. The problem is that "adb pull" will run as a shell user
what can't access to files created by lldb-server because they will be
owned by the application user. This CL changes the oat symbolization
code to run "oatdump --symbolize" to generate an output what is owned
by the shell user.
Differential revision: http://reviews.llvm.org/D13162
llvm-svn: 248788
See the script comments for how to modify your
pylintrc file (e.g. $HOME/.pylintrc) to support
always finding the lldb-specific Python library
directories.
With the pylintrc modification using this script,
the lldb python tests and test inferstructure can
be linted on any of potentially multiple lldb source
trees on the system without further work from
the developer.
llvm-svn: 248676
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Fix assignment operator in CMIUtilString to not crash the debugger if it
is passed a NULL pointer, which can happen in code like the following:
SBValue val;
CMIUtilString s;
//...
s = val.GetSummary();
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13094
llvm-svn: 248597
These tests used to hang on the old FreeBSD buildbot, which has been
retired. They do not hang when run locally, but do fail.
llvm.org/pr24939
llvm-svn: 248577
These tests were skipped because they hung the old FreeBSD buildbot.
They pass (and do not hang) when run locally so enable them again. We
will investigate further if they hang again once the new FreeBSD
buildbot is installed.
llvm.org/pr16684
llvm.org/pr18200
llvm.org/pr18230
llvm-svn: 248574
See:
https://llvm.org/bugs/show_bug.cgi?id=24926
for details. On OS X, when LLDB.framework is
not part of the lldb.dylib path, the supporting
executable path is resolved to be the bin directory
sitting next to the lib directory with the dylib
lives. Not a perfect solution, but we also can't
base it on the executable path since both Python
and the lldb driver can be the executable.
llvm-svn: 248545
Summary: This is no longer needed as this file no longer calls backtrace().
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13049
llvm-svn: 248457
Zachary Turner